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Executive  Summary 


Proprietary  three-dimensional  (3D)  technical  data  formats  are  useful  for  weapon 
system  design  but  do  not  support  all  downstream  uses  of  that  technical  data. 

The  Naval  Air  Systems  Command  (NAVAIR)  H-53  Heavy  Lift  Helicopter  Pro¬ 
gram  Office,  PMA-261,  manages  the  CH-53K  King  Stallion  helicopter  program, 
currently  in  the  Engineering  and  Manufacturing  Development  Phase  of  the  acqui¬ 
sition  cycle.  The  program  intends  to  design,  develop,  and  maintain  the  platform 
using  3D  models  documented  in  CATIA  computer-aided  design  (CAD)  software.1 
PMA-261 ’s  planned  approach  for  delivering  3D  technical  data  as  CATIA  models 
presents  a  challenge  for  Naval  Supply  Systems  Command  (NAVSUP)  and  the 
Defense  Logistics  Agency  (DLA)  Logistics  Information  Services  (LIS)  because 
their  current  provisioning  and  cataloging  processes  are  built  to  accommodate  and 
use  two-dimensional  (2D)  technical  data,  not  3D  models  in  proprietary  CAD  soft¬ 
ware  formats. 

Addressing  this  challenge  is  extremely  important  for  NAVSUP  and  DLA  because 
many  other  new  Navy  programs  are  taking  a  similar  approach  to  3D  technical 
data  for  thousands  of  new  parts.  They,  too,  will  soon  engage  NAVSUP  and  DLA 
for  assistance  and  support.  Their  inability  to  use  3D  models  in  proprietary  CAD 
software  formats  will  preclude  NAVSUP  and  DLA  LIS  from  conducting  their 
provisioning  and  cataloging  processes,  effectively  halting  development  and  im¬ 
plementation  of  the  requisite  supply  support  capability  for  new  weapon  system 
programs. 

Ultimately,  the  solution  for  the  CH-53K  3D  technical  data  challenge  may  become 
the  benchmark  for  addressing  similar  challenges  with  other  Navy  and  Department 
of  Defense  (DoD)  weapon  system  acquisition  programs.  Accordingly,  DLA 
wanted  PMA-261  and  NAVSUP  to  find  a  solution  to  ensure  NAVSUP  and  DLA’s 
ability  to  use  CH-53K  3D  technical  data  to  support  the  provisioning  and  catalog¬ 
ing  processes. 


1  CATIA  software  is  Dassault  Systems’  proprietary  3D  interactive  application  and  product 
development  platform  for  creating  system  design  models. 
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In  a  previous  task,2  we  conducted  an  research  and  development  project  focused  on 
CH-53K  technical  data  and  developed  a  mutually  acceptable  solution  by  which 
PMA-261  could  provide  3D  technical  data  to  DLA  to  support  the  sustainment 
process,  which  follows  the  provisioning  and  cataloging  processes  in  the  system 
life  cycle.  During  that  effort,  we  identified  the  3D  PDF  file  format  as  the  preferred 
means  for  ensuring  that  CH-53K  3D  technical  data  could  support  the  sustainment 
process  (for  details,  see  DL303T1).  We  specifically  noted  that  this  format  can  ac¬ 
commodate  the  full  product  definition  contained  in  the  native  CATIA  models  and 
can  be  easily  accessed  and  interpreted  by  procurement  personnel  without  the  need 
to  understand  or  use  complex  software  applications  (only  Adobe  Reader  or  Adobe 
Acrobat  software  are  needed  to  read/navigate  a  3D  PDF  file,  and  that  software  is 
already  installed  on  most  DoD  computers). 

For  the  same  reasons,  we  find  that  a  3D  PDF  solution  will  resolve  the  issue  of  ac¬ 
cess  and  readability  by  NAVSUP  and  DLA  personnel  as  they  perform  their  provi¬ 
sioning  and  cataloging  efforts,  respectively.  In  addition,  we  and  PMA-261  agree 
that  a  single  solution  for  the  CH-53K  program  is  preferred  for  supporting  the  pro¬ 
visioning,  cataloging,  and  sustainment  processes. 

PMA-261  agrees  with  the  3D  PDF  solution  and  is  working  with  the  NAVAIR  en¬ 
terprise  to  identify  a  funding  source;  the  outcome  is  to  be  determined.  To  help 
PMA-261  and  other  program  offices  calculate  the  startup  and  expected  annual 
costs  of  implementing  a  3D  PDF  solution,  we  identified  and  documented  the  re¬ 
quirements  and  associated  labor  hour  and  cost  elements.  Using  this  information, 
we  constructed  a  cost  analysis  tool,  an  Excel  spreadsheet. 

We  conclude  that  CH-53K  technical  data  issues  relative  to  supporting  the  provi¬ 
sioning  and  cataloging  processes  are  not  unique.  Navy  and  other  DoD  weapon 
system  programs  plan  to  use  3D  technical  data  as  part  of  a  model-based  enterprise 
approach  throughout  the  system’s  life  cycle.  However,  guidance  regarding 
3D  data  completeness  and  format  requirements  is  lacking.  In  general,  the  system 
designers  who  develop  the  native  CAD  files — which  should  be  the  basis  for  all 
follow-on  manufacturing  and  sustainment  activities  (provisioning,  cataloging, 
etc.) — rarely  include  (or  even  consider)  the  requirements  for  these  activities  in  the 
baseline  3D  models.  As  development  of  these  other  weapon  systems  continues, 
more  instances  of  3D  technical  data  that  cannot  support  the  provisioning  and  cata¬ 
loging  processes  will  arise. 

We  recommend  DLA  do  the  following  to  ensure  it  can  catalog  and  subsequently 
procure  parts  using  3D  technical  data  from  any  program  office: 

♦  Along  with  NAVSUP,  continue  a  regular  dialog  with  PMA-261  and  moni¬ 
tor  contract  efforts  and  the  program’s  ability  to  implement  a  3D  PDF  solu¬ 
tion  for  provisioning  and  cataloging,  including  conduct  of  a  proposed 


2  Thomas  K.  Parks  and  Dick  Tiano  (ATI),  Can  CH-53K  3D  Technical  Data  Support  the  DLA 
Sustainment  Process?,  DL303T1  (Tysons,  VA:  LMI,  February  2017). 
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Navy  MANTECH3  project  to  demonstrate  executing  a  3D  PDF  solution 
amongst  the  CH53K  program,  NAVSUP,  and  DLA. 

♦  Engage  with  select  working  groups  to  review  and  update  technical  data 
policy  to  specifically  address  requirements  for  3D  technical  data  formats. 

♦  Identify  and  characterize  other  military  service  programs  that  will 
deliver  3D  technical  data  to  DLA  in  the  next  5  years  and  identify 
appropriate  solutions  if  a  3D  PDF  method  cannot  be  implemented. 

♦  Officially  adopt  the  3D  PDF  file  as  the  desired  delivery  medium  of  3D 
technical  data  from  the  services  and  conduct  an  outreach  program  to  publi¬ 
cize  that  decision. 

We  recommend  that  PMA-261  engage  NAVAIR  management  and  seek  assistance 
in  procuring  funding  to  support  a  3D  PDF  enterprise  solution  for  providing 
NAVSUP  and  LIS  with  CH-53K  technical  data  to  support  the  provisioning  and 
cataloging  processes. 

If  the  enterprise  cannot  fund  or  implement  a  3D  PDF  solution  for  the  CH-53K 
program,  we  recommend  that  NAVAIR  have  PMA-261  engage  DLA  and 
NAVSUP  to  develop  an  acceptable  alternative  solution  for  providing  usable  tech¬ 
nical  data  to  support  the  provisioning  and  cataloging  processes. 

We  recommend  other  program  offices  do  the  following: 

♦  Review  their  program  technical  data  deliverables  and  determine  whether 
they  meet  the  DLA  characteristics  and  data  requirements  identified  in 
Appendix  A. 

♦  If  the  program  intends  to  receive  and  use  3D  (rather  than  2D)  technical 
data,  consider  implementing  a  3D  PDF  file  solution  as  the  delivery  format 
to  support  the  provisioning,  cataloging,  and  sustainment  processes. 


3  MANTECH  is  abbreviated  terminology  for  DoD  Manufacturing  Technology  Program. 
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Chapter  1 

Introduction 


The  CH-53K  King  Stallion  is  a  large,  heavy-lift  cargo  helicopter  being  developed 
by  Sikorsky  Aircraft  for  the  United  States  Marine  Corps  (USMC).  It  is  a  general 
redesign  of  the  current  CH-53E  featuring  new,  more  powerful  engines,  new 
lightweight  composite  structures,  fourth  generation  main  rotor  blades,  fly-by-wire 
flight  controls,  and  a  host  of  other  modern  design  features  intended  to  make  it 
more  intelligent,  reliable,  low  maintenance,  and  survivable  than  its  predecessors. 
The  USMC  is  planning  to  procure  about  200  CH-53Ks,  which  translates  into 
thousands  of  parts  that  will  require  provisioning  and  sustainment  support  from 
organizations  like  the  Defense  Logistics  Agency  (DLA)  and  the  Naval  Supply 
Systems  Command  (NAVSUP). 

The  Naval  Air  Systems  Command  (NAVAIR)  H-53  Heavy  Lift  Helicopter 
Program  Office,  PMA-261,  manages  the  program,  which  is  currently  in  the 
Engineering  and  Manufacturing  Development  Phase  of  the  acquisition  cycle.  The 
program  intends  to  design,  develop,  and  maintain  the  CH-53K  platform  using 
three-dimensional  (3D)  models  developed  in  CATIA1  computer-aided  design 
(CAD)  software.  PMA-261  originally  planned  to  deliver  the  CATIA  3D  models  to 
NAVSUP  and  DLA  as  the  requisite  technical  data  packages  to  support  the 
provisioning  process  for  the  CH-53K  platform,  expected  to  begin  in  the  second 
quarter  of  fiscal  year  2019. 

The  Problem 


PMA-261 ’s  planned  approach  for  delivering  3D  technical  data  as  CATIA  models 
presents  a  significant  challenge  for  NAVSUP  and  DLA  because  their  current 
provisioning  processes  are  built  to  accommodate  and  use  two-dimensional  (2D) 
technical  data,  not  3D  models.  Neither  NAVSUP  nor  DLA  have  any  credible 
capability  to  access,  view,  or  interpret  technical  data  delivered  as  3D  models  in 
any  of  the  multiple,  proprietary  CAD  software  systems  (CATIA,  SolidWorks, 
CREO,  NX,  AutoCAD,  etc.). 

Addressing  the  challenge  of  using  CH-53K  3D  technical  data  to  support  the 
provisioning  process  is  extremely  important  for  NAVSUP  and  DLA  because 
many  other  new  weapon  system  programs  are  taking  a  similar  approach  to 
developing  and  providing  only  3D  technical  data  for  thousands  of  new  parts. 
They,  too,  will  soon  engage  NAVSUP  and  DLA  for  provisioning  assistance  and 
support.  Ultimately,  the  solution  for  the  CH-53K  3D  technical  data  challenge  may 


1  CATIA  software  is  Dassault  Systems’  proprietary  3D  interactive  application  and  product 
development  platform  for  creating  system  design  models. 


1-1 


become  the  benchmark  for  addressing  similar  challenges  with  other  Navy  and 
Department  of  Defense  (DoD)  weapon  system  acquisition  programs. 


The  Solution 


In  a  previous  task,  DLA  engaged  LMI  to  conduct  a  research  and  development 
(R&D)  project  focused  on  CH-53K  technical  data  and  develop  a  mutually  ac¬ 
ceptable  solution  by  which  PMA-261  could  provide  3D  technical  data  to  DLA  to 
support  the  sustainment  process,  which  follows  the  provisioning  process  in  the 
system  life  cycle.  During  that  effort,  we  became  aware  of  the  issue  of  using  CH- 
53K  3D  technical  data  to  support  the  provisioning  process,  scheduled  to  begin  in 
the  second  quarter  of  fiscal  year  2018. 

As  part  of  the  previous  effort,  we  reviewed  CH-53K  CATIA  models  using  a  vari¬ 
ety  of  software  products,  including  CATIA  CAD  software.  We  assessed  the  abil¬ 
ity  of  the  existing  CH-53K  models  to  meet  DLA’s  data  requirements  to  support 
procurement  actions.  We  explored  various  ways  to  solve  the  issue  and  identified 
the  use  of  neutral  file  formats  like  3D  PDF  and  Standard  for  the  Exchange  of 
Product  model  data  (STEP)  as  a  solution  mutually  acceptable  to  PMA-261  and 
DLA.  We  also  estimated  the  time  and  cost  associated  with  implementing  a  3D 
PDF  solution.  We  documented  all  of  our  work,  including  our  findings,  conclu¬ 
sions,  and  recommendations.2 

Because  of  contractual  limitations,  we  could  not  address  the  provisioning  issue  as 
part  of  our  previous  work.  DLA  recognized  the  significant  implications  and  im¬ 
mediacy  of  the  CH-53K  3D  technical  data  issue  and  awarded  LMI  a  follow-on 
R&D  task  specifically  to  address  the  use  of  3D  technical  data  to  support  the  provi¬ 
sioning  process.  This  task  builds  directly  upon  the  knowledge  and  insights  we  ac¬ 
cumulated  as  part  of  the  previous  work  to  understand  the  full  extent  and  content 
of  the  CH-53K  CATIA  3D  models. 

This  report,  covering  the  use  of  CH-53K  3D  technical  data  to  support  the  provi¬ 
sioning  process,  is  an  adjunct  to  LMI  Report  DL303T1.  It  documents  our  specific 
research  findings  and  conclusions  regarding  DLA  and  NAVSUP’s  capabilities  to 
use  3D  data,  provisioning  process  data  requirements,  and  the  ability  of  the 
CH-53K  technical  data  to  support  the  provisioning  and  cataloging  processes. 
Further,  it  recommends  a  mutually  agreeable  solution,  by  which  PMA-261  can 
furnish  CH-53K  3D  technical  data  to  NAVSUP  and  DLA  in  a  format  they  can  use 
to  execute  the  provisioning  and  cataloging  processes. 


2  Thomas  K.  Parks  and  Dick  Tiano  (ATI),  Can  CH-53K  3D  Technical  Data  Support  the  DLA 
Sustainment  Process?,  DL303T1  (Tysons,  VA:  LMI,  February  2017). 


1-2 


Chapter  2 

Provisioning  Process  Technical  Data 


To  execute  the  provisioning  and  cataloging  processes,  the  performing  activities 
need  system  design  technical  data  that  describe  the  various  systems,  subsystems, 
and  components  of  the  weapon  system  platform.  Traditionally,  those  technical 
data  have  been  delivered  as  2D  parts  lists,  2D  maintenance  plans,  and  2D 
drawings  depicting  the  system  design.  For  the  CH-53K  program,  3D  models  will 
be  delivered  in  lieu  of  2D  drawings. 

Overview 


“Provisioning  is  the  process  of  determining  and  acquiring  the  range  and 
quantity  (depth)  of  repair  parts,  and  support  and  test  equipment  required 
to  operate  and  maintain  an  end  item  of  material  for  an  initial  period  of 
service.  [Typically,  provisioning]  refers  to  first  outfitting  of  a  ship,  unit, 
or  a  system.”1  It  is  the  first  phase  in  developing  a  supply  support  capability 
for  a  weapon  system  like  the  CH-53K. 

Provisioning  is  an  integral  part  of  supply  chain  management  and  closely  aligned 
with  cataloging.  Cataloging  is  the  process  of  systematically  arranging  and 
accounting  for  items  with  descriptive  details,  including  “naming,  describing, 
classifying,  and  assigning  a  unique  combination  of  letters  or  numerals,  or  both.”2 
In  DoD,  cataloging  is  a  prerequisite  for  effective  supply  chain  management 
because  it  standardizes  supplies  and  assets  that  will  be  recurrently  procured, 
stocked,  or  distributed. 

This  report  focuses  on  the  technical  data  requirements,  data  formats,  and  data 
flow  to  support  the  provisioning  and  cataloging  processes  for  the  CH-53K 
program.  The  sections  that  follow  describe  the  organizations  and  roles  relative  to 
the  provisioning  and  cataloging  processes,  technical  data  requirements  and 
formats,  and  current  (“as-is”)  process  flow  for  the  CH-53K  program. 


1  Defense  Acquisition  University  ACQuipedia,  Provisioning,  https://dap.dau.mil/ 
acquipedia/Pages/ArticleDetails.aspx?aid=8478d478-c7c8-4df2-b23d-bl47f671fd44. 

2  Defense  Acquisition  University  ACQuipedia,  https://dap.dau.mil/acquipedia/Pages/ 
ArticleDetails.aspx?aid=23ea92bl-b38b-4328-8a4e-e0ba884d2d3b. 
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CH-53K  Program  Organizational  Roles 


Four  principal  organizations  are  involved  in  the  CH-53K  program  provisioning 
and  cataloging  processes: 

♦  Sikorsky  Aircraft,  the  original  equipment  manufacturer  (OEM) 

♦  PMA-261,  the  CH-53K  program  office 

♦  NAVSUP  Weapon  Systems  Support  (WSS)  Philadelphia,  the  Navy 
provisioning  activity 

♦  DLA  Logistics  Information  Service  (LIS),  the  DoD  cataloging  activity. 

Each  activity  has  specific  responsibilities  and  takes  actions  in  the  provisioning 
and  cataloging  process. 

Original  Equipment  Manufacturer 

Sikorsky  Aircraft  develops,  designs,  and  delivers  the  CH-53K  helicopter  system 
in  accordance  with  its  government  contract.  This  includes  development  of  3D 
models  in  a  CATIA  CAD  format  that  completely  document  the  system  design.  As 
the  OEM,  Sikorsky  also  develops  a  preliminary  provisioning  parts  list  (PPL)  and 
a  maintenance  plan,  which  will  be  used  to  support  the  provisioning  and  cataloging 
processes. 


PMA-261 

Among  other  things,  the  program  office  ensures  the  OEM  meets  its  contractual  re¬ 
quirements  relative  to  developing  and  delivering  technical  data  for  the  CH-53K 
system.  PMA-261  also  stores  and  manages  that  design  data  for  subsequent  use 
during  the  CH-53K  life  cycle. 

NAVSUP  WSS 

NAVSUP  reviews  the  provisioning  technical  documentation  and  makes 
provisioning  decisions,  including  determining  whether  an  item  of  supply  will  be 
managed  by  the  Navy  or  DLA.  The  provisioning  technical  decisions  are  made 
based  on  the  maintenance  significance  of  an  item,  how  it  will  be  used,  and  where 
it  will  be  used.  These  decisions  translate  technical  maintenance  questions  into 
language  used  by  the  supply  system,  and  they  typically  are  documented  by 
assignment  of  codes  in  the  PPL,  such  as  the  following: 

♦  Should  a  part  be  stocked?  (Source  code) 

♦  Who  can  replace  a  part?  (Replace  maintenance  code) 
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♦  Who  can  repair  a  part?  (Repair  maintenance  code) 

♦  Who  is  the  part  disposal  authority?  (Recoverability  code) 

♦  What  is  the  replacement  frequency?  (Replacement  factor) 

♦  What  is  the  replacement  quantity?  (Minimum  replacement  unit) 

♦  How  important  is  an  item?  (Military  essentiality  code). 

The  process  of  decision  making  and  recording — commonly  called  “provisioning 
technical  coding” — is  based  on  a  thorough  review  of  the  provisioning  technical 
documentation  submitted  by  the  OEM  and  the  program  office,  including  system 
design  data. 


DLA  LIS 

As  the  DoD’s  cataloging  agent,  DLA  LIS  is  responsible  for  data  strategy,  man¬ 
agement,  operational  control,  and  data  support  for  all  National  Stock  Number 
(NSN)  items  in  the  Lederal  Catalog  System  (LCS)  used  in  supply  management 
operations  by  the  military  services,  other  DoD  activities,  federal  and  civilian 
agencies,  and  foreign  governments.  Lor  the  CH-53K  program,  DLA  LIS  will  do 
the  following: 

♦  Assign  an  item  name  by  designating  a  commonly  recognized  noun  or  noun 
phrase  to  an  item  of  supply. 

♦  Determine  the  Lederal  Supply  Class  of  an  item  of  supply  by  establishing 
its  relationship  with  other  items,  based  on  the  assigned  item  name  or  phys¬ 
ical  and  performance  characteristics. 

♦  Prepare  and  maintain  an  item  identification  by  recording  the  characteris¬ 
tics  data  to  describe  the  physical  and  performance  attributes  of  an  item  of 
supply. 

♦  Control  item  entry  (filtering  and  scrutinizing  a  candidate  for  inclusion  in 
the  LCS)  by  manually  and  mechanically  comparing  a  candidate  to  existing 
items  and  recognized  standards. 

Results 


The  four  activities  perform  these  actions  using  the  provisioning  technical  docu¬ 
mentation  submitted  by  NAVSUP  WSS,  including  the  updated  PPL,  maintenance 
plan,  and  system  design  documentation  (3D  models  for  the  CH-53K). 

As  a  team,  they  must  fulfill  their  individual  requirements  and  work  together  to  de¬ 
velop  and  transfer  a  complete,  usable  set  of  technical  data  to  ensure  execution  of 
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the  provisioning  and  cataloging  processes  for  the  CH-53K  program.  Accomplish¬ 
ment  of  these  processes  is  a  prerequisite  for  developing  and  implementing  a  sus¬ 
tainable  life-cycle  supply  support  capability. 


Data  Requirements  and  Process  Flow 


This  section  describes  the  3D  technical  data  requirements,  formats,  and  as-is  tech¬ 
nical  data  flow  for  the  CH-53K  program  provisioning  and  cataloging  processes. 

3D  Data  Requirements  for  Provisioning  and  Cataloging 

Provisioning  technical  documentation  for  the  CH-53K  program  currently  includes 
a  PPL,  maintenance  plan,  and  system  design  documentation  in  the  form  of 
CATIA-based  3D  models.  The  data  requirements  and  formats  for  the  PPL  and 
maintenance  plan  are  standard  for  DoD  and  have  not  been  changed  for  the 
CH-53K  program  provisioning  and  cataloging  processes.  On  the  other  hand,  the 
CH-53K  system  design  documentation  format  of  CATIA  3D  models  (in  lieu  of 
2D  drawings)  is  new  and  has  never  been  used  by  NAVSUP  WSS  or  DLA  LIS  in 
the  provisioning  and  cataloging  processes.  Accordingly,  this  report  only  addresses 
the  data  requirements  and  formats  for  the  system  design  models. 

Discussions  with  NAVSUP  WSS  and  DLA  LIS  regarding  design  documentation 
minimum  data  requirements  to  support  the  provisioning  and  cataloging  processes 
revealed  they  are  basically  the  same  as  the  sustainment  process  data  requirements 
(Appendix  A).  Both  organizations  confirmed,  if  provided  design  data  (that  they 
can  access,  view,  and  read)  that  include  all  the  characteristics  and  data  elements  in 
Appendix  A,  they  will  have  ample  detail  to  make  informed  provisioning  technical 
decisions  and  adequately  catalog  all  of  the  requisite  CH-53K  items. 

Provisioning  and  Cataloging  Data  Flow 

To  fully  understand  the  provisioning  and  cataloging  processes  and  interactions 
between  the  different  organizations,  we  constructed  a  flow  diagram  for  the  tech¬ 
nical  data,  as  it  would  occur  today — the  as-is  data  flow  (Figure  2-1).  We  provided 
copies  of  the  diagram  to  PMA-261,  NAVSUP,  and  DLA  LIS,  asking  them  to  re¬ 
view  and  validate  the  data  flow.  Each  activity  furnished  comments,  which  we  in¬ 
corporated  to  ensure  the  diagram  correctly  depicts  the  data  artifacts  and  flow.  The 
same  organizations  validated  the  revised  diagram.  (Appendix  B  details  each  dia¬ 
gram  icon.) 
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Provisioning  Process  Technical  Data 


Figure  2-1.  CH-53K  Provisioning  Technical  Data  Flow  (As- Is) 


Note:  DMS  =  Data  Management  System;  FLIS  =  Federal  Logistics  Information  System; 
ICAPS  =  Interactive  Computer  Aided  Provisioning  System;  JEDMICS  =  Joint  Engineering  Data 
Management  Information  and  Control  System;  SSR  =  supply  support  request. 


The  data  flow  between  the  four  activities  in  the  provisioning  and  cataloging  pro¬ 
cesses  is  as  follows: 

♦  OEM.  At  the  process  start,  the  OEM  creates  the  various  technical  docu¬ 
ments  (PPL,  maintenance  plan,  and  3D  models)  used  to  support  the  provi¬ 
sioning  and  cataloging  activities.  The  OEM  transfers  the  technical  data 
directly  to  PMA-261  and  NAVSUP. 

♦  PMA-261.  The  program  office  receives  and  stores  the  technical  data  on  a 
local  share  drive  and  then  reviews  the  documents  to  validate  they  meet  the 
contract  requirements.  Subsequently,  PMA-261  posts  the  design  data  (3D 
models)  to  the  JEDMICS  database  for  use  during  system  sustainment. 

♦  NAVSUP.  The  provisioning  group  at  NAVSUP  (WSS  Philadelphia)  re¬ 
ceives,  directly  from  the  OEM,  the  same  technical  data  as  PMA-261.  Like 
PMA-261,  NAVSUP  initially  stores  all  of  the  received  technical  data  on  a 
local  share  drive.  Subsequently,  it  transfers  the  PPL  to  the  ICAPS  database 
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and  transfers  the  3D  models  to  its  (local)  technical  library.  NAVSUP  pro¬ 
visioning  personnel  then  access  the  technical  data  as  necessary  to  review 
and  validate  OEM  provisioning  inputs,  make  appropriate  provisioning 
technical  decisions,  and  record  those  decisions  in  the  PPL. 

During  the  provisioning  process,  NAVSUP  may  request  DLA  LIS  assis¬ 
tance  (the  dotted  line  in  Ligure  2-1)  in  reviewing  the  technical  data  to  en¬ 
sure  they  properly  reflect  identification  of  existing  NSNs  and  to  provide 
additional  research  to  support  provisioning  technical  decisions.3  Lollowing 
completion  of  the  formal  provisioning  process  activities,  NAVSUP  issues 
a  SSR  to  DLA  LIS  to  begin  the  cataloging  process.  NAVSUP  also  trans¬ 
fers  the  3D  models  from  its  technical  library  to  the  SCAN  Data  digital  re¬ 
pository. 

♦  DLA  LIS.  Upon  receipt  of  the  SSR  from  the  provisioning  agent,  DLA  LIS 
begins  the  formal  cataloging  process.  It  uses  the  information  in  the  SSR 
and  design  data  (3D  models)  to  make  decisions  on  naming,  describing, 
and  numbering  each  item  (assigning  an  NSN).  Subsequently,  the  cata¬ 
loged  post  this  information  to  the  LLIS  database  for  use  during  system 
sustainment.  They  also  transfer  the  design  data  (3D  models)  to  the  DMS 
digital  repository  for  use  by  the  various  DLA  supply  centers  during  system 
sustainment. 

As  noted  in  Chapter  1,  the  CH-53K  provisioning  process  is  scheduled  for  the 
second  quarter  of  fiscal  year  2018.  Ligure  2-1  accurately  depicts  the  data  flow, 
data  artifacts  that  would  pass  between  the  various  organizations,  data  storage,  and 
the  provisioning  and  cataloging  activities  that  should  take  place  at  that  time. 

However,  neither  NAVSUP  nor  DLA  LIS  can  actually  use  the  OEM-provided  3D 
models  to  perform  their  assigned  responsibilities.  Neither  organization  has 
suitable  software  or  the  associated  training  to  use  native  3D  models.  Thus,  they 
cannot  access  and  display  the  full  product  definition  contained  in  any  proprietary 
CAD  software  format  (CATIA,  CREO,  NX,  SolidWorks,  AutoCAD,  etc.). 

Their  inability  to  use  the  CH-53K  CATIA  models  will  preclude  NAVSUP  and 
DLA  LIS  from  conducting  their  provisioning  and  cataloging  processes.  Both 
organizations  agree  that  a  different  model  format  is  needed  to  facilitate  the 
processes.  The  next  chapter  presents  a  potential  solution  to  the  problem. 


3  Only  NAVSUP,  the  provisioning  agent,  can  make  and  issue  provisioning  technical  decisions 
for  the  CH-53K  platform.  DLA  LIS  participation  in  the  provisioning  process  is  strictly  in  support 


of  NAVSUP. 
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Chapter  3 

3D  Technical  Data  Solution  for  Provisioning 


In  our  earlier  report,1  we  detail  the  current  status  of  the  CH-53K  engineering  data 
for  provisioning  (EDFP)  design  models.  We  found  the  CH-53K  EDFP  models 
could  not  support  the  DLA  sustainment  process.  Specifically,  they  lack  virtually 
all  of  the  characteristics  and  data  elements  in  Appendix  A  (except  for  geometry 
and  some  dimensional  information),  which  contains  the  minimum  data  require¬ 
ments  for  sustainment. 

In  keeping  with  our  findings  regarding  the  EDFP  models — corroborated  in  an  in¬ 
dependent  evaluation  by  the  engineering  support  activity  (ESA)  at  Cherry  Hill — 
PMA-261  rejected  delivery  of  the  models  and  directed  the  OEM  to  modify  them 
to  include  the  requisite  information,  including  tolerances,  datum,  and  procurement 
metadata. 

We  met  with  representatives  from  NAVSUP  WSS  and  LIS  to  discuss  their  data 
requirements  to  conduct  the  provisioning  and  cataloging  processes,  respectively. 
Specifically,  we  asked  how  their  data  needs  compared  with  the  data  requirements 
for  the  sustainment  process  (Appendix  A).  Both  organizations  told  us  that  the  in¬ 
formation  they  require  from  the  design  data  is  basically  the  same  as  that  needed  to 
support  the  sustainment  process.  So,  if  the  design  data  documentation  meets  the 
data  requirements  (Appendix  A)  to  support  the  sustainment  process,  it  also  will 
provide  all  of  the  data  needed  to  carry  out  the  provisioning  and  cataloging 
processes. 

Assuming  the  OEM  modifies  the  EDFP  models  to  include  the  minimum  data  re¬ 
quirements  for  sustainment,  the  CATIA  3D  models  also  will  meet  the  technical 
data  needs  of  the  provisioning  and  cataloging  processes  as  confirmed  by  the 
NAVSUP  and  LIS  representatives.  However,  that  solution  does  not  solve  the  ina¬ 
bility  of  NAVSUP  and  DLA  to  access  and  display  the  full  product  definition  con¬ 
tained  in  the  proprietary  CATIA  software  format  used  to  create  and  document  the 
3D  design  models. 

Fortunately,  the  proposed  solution  for  providing  useable  CH-53K  3D  technical 
data  to  DLA  to  support  the  sustainment  process  (3D  PDF)  can  also  solve  the  simi¬ 
lar  issue  of  providing  usable  technical  data  for  the  provisioning  and  cataloging 
processes,  as  described  below. 


1  See  Note  2,  Chapter  1 . 
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The  Preferred  Solution:  3D  PDF 


We  identified  a  3D  PDF  solution  as  the  preferred  means  for  ensuring  that 
CH-53K  3D  technical  data  could  support  the  sustainment  process  (for  details,  see 
DL303T1).  We  specifically  noted  that  this  format  can  accommodate  the  full  prod¬ 
uct  definition  contained  in  the  native  CATIA  models  and  can  be  easily  accessed 
and  interpreted  by  procurement  personnel  without  the  need  to  understand  or  use 
complex  software  applications  (only  Adobe  Reader  or  Adobe  Acrobat  software 
are  needed  to  read/navigate  a  3D  PDF  file). 

For  the  same  reasons,  we  find  that  a  3D  PDF  solution  will  resolve  the  issue  of 
access  and  readability  by  NAVSUP  and  LIS  personnel  as  they  perform  their  pro¬ 
visioning  and  cataloging  efforts,  respectively.  In  addition,  we  and  PMA-261  agree 
that  a  single  solution  for  the  CH-53K  program  is  preferred  for  supporting  the 
sustainment,  provisioning,  and  cataloging  processes. 

As  long  as  the  CH-53K  native  CATIA  design  models  (1)  contain  the  minimum 
required  data  characteristics  and  elements  (Appendix  A)  and  (2)  are  fully  anno¬ 
tated,  they  can  be  converted  to  3D  PDF  files  that  contain  the  full  product  defini¬ 
tion  and  are  accessible  and  readable  by  NAVSUP  and  LIS  personnel.  Accordingly, 
the  3D  PDF  files  can  be  substituted  for  the  native  CATIA  3D  models  as  the  sys¬ 
tem  design  data  documentation,  or  medium,  provided  to  NAVSUP  and  LIS  per¬ 
sonnel  performing  the  provisioning  and  cataloging  functions.  The  next  section 
describes  how  the  implementation  of  a  3D  PDF  solution  will  affect  the  provision¬ 
ing  and  cataloging  data  flow  and  processes. 

Data  Flow  Using  3D  PDF  Data 


Figure  2-1  depicts  the  as-is  technical  data  flow  for  the  CH-53K  provisioning  and 
cataloging  processes.  It  is  based  on  the  use  of  CATIA  3D  models  to  convey  sys¬ 
tem  design  data.  If  PMA-261  implements  a  3D  PDF  solution  consistent  with  its 
plans  for  supporting  the  sustainment  process,  the  data  artifacts  and  data  flow  will 
change.  Accordingly,  we  developed  a  revised  technical  data  flow  depicting  the 
new  artifacts  and  flow  process. 

The  overall  provisioning  and  cataloging  processes  do  not  change  with  the  use  of 
3D  PDF  technical  data.  Similarly,  the  PPL  and  maintenance  plan  data  artifacts  do 
not  change.  The  principal  changes  relate  to  where  the  3D  PDF  data  artifact  is  cre¬ 
ated  and  how  it  is  provided  to  NAVSUP  as  part  of  the  overall  data  flow  of  tech¬ 
nical  data  in  the  provisioning  and  cataloging  processes.  Figure  3-1  shows  the 
projected  (“to-be”)  data  flow  for  a  3D  PDF  solution. 

The  paragraphs  that  follow  broadly  describe  the  changes  in  the  data  flow  to  ac¬ 
commodate  the  implementation  of  a  3D  PDF  solution  as  part  of  the  provisioning 
and  cataloging  processes.  (Appendix  B  details  the  diagram  icons.) 
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3D  Technical  Data  Solution  for  Provisioning 


Figure  3-1.  Provisioning  Technical  Data  Flow  Using  3D  PDF  Data  (To-Be) 


Note:  PLM  =  product  life  cycle  management. 


The  to-be  data  flow  between  the  four  activities  in  the  provisioning  and  cataloging 
processes  is  as  follows: 

♦  OEM.  The  OEM  delivers  3D  models  in  the  native  CATIA  format  to 
PMA-261  only. 

♦  PMA-261.  The  program  office  stores  all  of  the  OEM  deliverables  in  a 
PLM  system  database.2  The  PLM  system  also  houses  the  software  for  cre¬ 
ating  and  validating  3D  PDF  documents  and  it  maintains  associativity  be¬ 
tween  the  models  and  other  files.  The  program  office  uses  the  installed 
software  to  convert  the  native  CATIA  models  to  3D  PDF  files  and  validate 
those  files  against  the  original  CATIA  model.  It  stores  the  3D  PDF  files  in 
the  PLM  system  to  facilitate  data  management  during  the  remainder  of  the 
system  life  cycle.  It  transfers  a  copy  of  the  3D  PDF  files,  with  full  associa¬ 
tivity,  to  NAVSUP. 


2  PMA-261  planned  to  implement  a  PLM  system  before  it  considered  a  3D  PDF  solution. 
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♦  NAVSUP.  The  provisioning  group  at  NAVSUP  (WSS  Philadelphia)  re¬ 
ceives  the  3D  PDF  files  directly  from  PMA-261  and  initially  stores  them 
on  a  local  share  drive  before  transferring  them  to  its  (local)  technical  li¬ 
brary.  It  uses  the  3D  PDF  files  to  perform  the  provisioning  process,  and 
then  transfers  a  copy  of  the  files  to  the  SCAN  Data  digital  repository  at 
LIS. 

♦  LIS.  LIS  uses  the  3D  PDF  files  to  perform  the  cataloging  process  and  sub¬ 
sequently  transfer  a  copy  of  those  files  to  the  DMS  digital  repository  for 
use  by  the  various  DLA  supply  centers  during  system  sustainment. 

Using  3D  PDF  files  (in  lieu  of  the  native  3D  models)  will  enable  NAVSUP  and 
LIS  to  perform  their  provisioning  and  cataloging  responsibilities  without  acquir¬ 
ing  software,  licenses,  and  training  for  the  various  CAD  software  systems  cur¬ 
rently  in  use  by  the  OEMs  designing  and  building  weapon  systems  for  DoD.  The 
use  of  3D  PDF  files  will  not  materially  change  the  provisioning  and  cataloging 
process  steps.  However,  use  of  3D  PDF  files  that  meet  the  data  requirements  of 
Appendix  A  will  improve  the  provisioning  and  cataloging  processes  because  they 
provide  a  clear  representation  of  the  design  intent  and  reduce  ambiguity  regarding 
item  characteristics.  The  next  chapter  covers  the  cost  of  implementing  a  3D  PDF 
solution  for  the  CH-53K  and  other  DoD  programs. 
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Chapter  4 

3D  PDF  Solution  Costs 


To  help  DLA,  PMA-261,  and  other  program  offices  that  are  acquiring  3D 
technical  data  estimate  the  cost  of  implementing  a  3D  PDF  solution  to  support 
sustainment,  we  describe  the  minimum  requirements  and  offer  some  cost 
information  in  the  following  sections.  We  then  present  a  notional  business  case 
analysis  (BCA)  for  implementing  a  3D  PDF  solution  for  a  program  on  the  basis  of 
our  cost  information,  which  we  incorporated  in  a  Microsoft  Excel  spreadsheet  as 
an  addendum  to  this  report.  The  spreadsheet  contains  data  elements  and  labor 
estimates  for  the  minimum  requirements  discussed. 

Solution  Requirements 


Any  program — regardless  of  its  position  in  the  acquisition  life  cycle — has 
six  minimum  requirements  for  implementing  a  3D  PDF  solution  to  support  the 
sustainment  process: 

1.  Native  CAD  models  must  be  fully  populated  with  the  minimum  data  ele¬ 
ment  requirements  (Appendix  A). 

2.  Dimensions,  tolerances,  datum,  and  procurement  metadata  (Appendix  A) 
included  in  native  CAD  models  must  be  annotated. 

3.  A  3D  PDF  conversion  software  application  must  be  acquired  and 
supported. 

4.  A  template  that  defines  the  format  of  the  3D  PDF  output  file  must  be  cre¬ 
ated,  and  it  must  include  all  of  the  sustainment  data  requirements 
(Appendix  A). 

5.  Native  CAD  files  for  each  part  identified  as  a  candidate  for  competitive 
procurement  by  DLA  or  a  service  sustainment  activity — such  as 
NAVSUP,  Army  Materiel  Command,  or  Air  Force  Materiel 
Command — must  be  converted  to  a  3D  PDF  (PRC) 1  file  and  validated. 

6.  For  each  part  converted  to  a  3D  PDF  file,  the  corresponding  native  CAD 
file  must  be  converted  to  a  STEP  (AP203)  file  and  validated. 


1  PRC  stands  for  product  representation  compact,  one  of  two  systems  used  to  embed  3D  inter¬ 
active  data  and  models  into  a  PDF  document. 
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The  next  section  addresses  the  cost  associated  with  each  of  the  six  requirements 
for  implementing  a  3D  PDF  solution  to  support  sustainment. 


Solution  Costs 


The  costs  associated  with  implementing  a  3D  PDF  solution  will  vary  from  one 
program  to  the  next,  depending  on  the  number  and  complexity  of  the  models  or 
parts  that  will  be  competitively  procured.  Final  costs  also  depend  on  the  actual  or 
assumed  labor  rate  associated  with  carrying  out  a  specific  requirement.  For  each 
requirement  that  requires  manual  labor,  we  provide  an  estimated  time  to  complete 
the  activity,  which  can  then  be  multiplied  by  an  appropriate  labor  rate  (as 
designated  by  the  program)  and  number  of  repetitions  (such  as  models  requiring 
conversion)  to  arrive  at  an  estimated  cost. 

We  also  provide  costs,  collected  from  vendors  or  their  websites,  to  procure  and 
maintain  automated  software.  These  costs  are  relatively  stable  and  consistent 
regardless  of  the  program. 

Populating  Native  CAD  Files  with  Sustainment  Data 
(Requirement  1) 

The  OEM  normally  populates  native  CAD  files  with  the  minimum  data  require¬ 
ments  (Appendix  A).  It  should  not  create  any  additional  cost  because  the  sustain¬ 
ment  requirements  have  not  changed  since  programs  shifted  to  3D  technical  data. 
(The  only  thing  that  has  changed  is  the  medium  in  which  the  data  are  documented 
and  transmitted  to  the  government.)  However,  if  the  appropriate  requirements 
were  not  included  in  the  original  or  current  contract,  there  will  be  an  additional 
cost,  which  will  vary  for  each  program  on  the  basis  of  the  number  of  parts  to  be 
competitively  procured. 

Annotating  Native  CAD  Files  (Requirement  2) 

The  OEM  normally  annotates  the  dimensions,  tolerances,  datum,  and  procurement 
metadata  in  the  native  CAD  models.  The  cost  varies  from  program  to  program, 
depending  on  the  number  of  models  that  require  annotation  and  the  complexity  of 
each,  measured  by  the  number  of  dimensions,  tolerances,  and  datum  contained. 

We  took  10  unannotated  CH-53K  EDFP  models  of  varying  complexity,  annotated 
them  using  applications  included  in  the  CATIA  CAD  software,  and  recorded  the 
time  it  took.  Table  4-1  shows  the  time  required  to  annotate  the  10  models. 
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3D  PDF  Solution  Costs 


Table  4-1.  Time  Required  to  Annotate  CAD  Models  (Minutes) 


EDFP  model  number 

Annotations  per  model 

Time  (minutes) 

06208-07001-101— A 

3 

10 

D38999_20JJ35HN 

15 

45 

HST10YV-6-5 

10 

30 

HST1 572ZAWT1 6 

8 

25 

M81714_63-20F_TL 

13 

30 

NASI 149C0332R 

3 

10 

NASI  791 C3-3 

17 

60 

HL78-6 

10 

60 

19205_6528256 

327 

960 

19205_7266834 

82 

240 

In  all  instances,  we  found  that  the  average  time  to  perform  an  annotation  was 
about  3  minutes.  Multiplying  this  figure  by  the  number  of  dimensions,  tolerances, 
datum,  and  procurement  metadata  in  each  model,  and  then  by  the  estimated  labor 
rate  for  the  designer  performing  the  annotations,  renders  an  estimated  cost  for  this 
activity.  Assuming  a  labor  rate  of  $1 15  per  hour,2  the  cost  of  one  annotation  is 
$5.75,  so  the  cost  to  annotate  a  single  model  that  has  100  annotations  is  about 
$575. 

Acquiring  and  Maintaining  3D  PDF  Conversion  Software 
(Requirement  3) 

The  cost  of  acquiring  and  supporting  a  3D  PDF  conversion  software  application 
varies  depending  on  the  specific  application.  Basically,  three  categories  of 
software  are  used  to  create  3D  PDF  output  files: 

♦  Software  embedded  in  the  basic  CAD  platform.  Most  CAD  platforms  con¬ 
tain  this  capability  at  no  extra  cost,  but  the  output  file  is  generally  only  a 
tessellated  image  without  annotated  dimensions,  tolerances,  datum,  or 
metadata. 

♦  Add-on  software  produced  by  the  CAD  platform  developer.  This  software 
(such  as  Solidworks  MBD  or  CATIA  Composer)  must  be  procured  at  an 
additional  cost. 


2  Market  rate  (loaded)  for  a  CAD  system  engineer,  with  a  BS,  8-10  years  of  experience, 
stationed  in  the  National  Capital  Region,  and  with  an  8  percent  fee,  as  identified  using  the  HR3D 
Premium  Tool. 
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♦  Third-party  software.  This  software,  created  by  independent  companies 
not  directly  owned  by  the  CAD  platform  developer  (such  as  Anark  Core 
workstation,  Tetra4D,  or  Lattice  Technology),  must  be  procured  at  an 
additional  cost. 

In  the  case  of  CATIA  CAD  products  (the  CAD  software  used  by  the  CH-53K 
OEM),  the  user  must  purchase  the  CATIA  Composer  software  and  use  it  in 
conjunction  with  the  CATIA  CAD  software  and  native  CAD  files  to  create  a  3D 
PDF  output  file  that  can  be  used  for  sustainment.  The  license  and  maintenance 
costs  of  the  CATIA  Composer  software  are  as  follows: 

♦  Perpetual  License  for  3DVIA  Composer-Configuration  (Primary  License 
Charge) — about  $7,500 

♦  Maintenance  for  3DVIA  Composer-Configuration  (Annual  License 
Charge) — about  $2,400. 

For  third-party  software,  Table  4-2  shows  estimated  price  ranges  for  3D  PDF 
conversion  software  workstation  solutions,  which  include  the  cost  for  a  single 
instance,  or  seat,  of  the  software.  Table  4-3  shows  estimated  price  ranges  for 
third-party  3D  PDF  conversion  software  server  solutions,  which  include  the  cost 
of  the  software  and  a  limited  number  of  seats  for  using  the  server  software.  The 
ranges  are  based  on  the  different  options  available  with  each  of  the  3D  PDF 
conversion  software  packages.  The  appropriate  options  for  a  given  situation 
depend  on  the  user’s  requirements.  All  of  the  options  included  in  these  ranges  can 
provide  all  the  required  product  and  manufacturing  information  (PMI)3  needed  for 
procurement.  We  obtained  these  prices  from  technical  representatives  at  each  3D 
PDF  conversion  software  company. 

Table  4-2.  Estimated  3D  PDF  Conversion  Software  Workstation  Costs  ($) 


Category 

Anark 

Lattice  technology 

Tetra4D 

Software 

12,000-16,000 

7,000-22,000 

500 

Annual  maintenance 

3,000-4,000 

1 ,500-4,000 

Not  applicable 

Table  4-3.  Estimated  Third-Party  3D  PDF  Conversion  Software  Server  Costs  ($) 


Category 

Anark 

Lattice  technology 

Tetra4D 

Software 

93,000-115,000 

26,000-115,000 

Not  applicable 

Annual  maintenance 

23,000-29,000 

5,000-23,000 

Not  applicable 

3  PMI  may  include  geometric  dimensions  and  tolerances,  3D  annotation  (text)  and 
dimensions,  surface  finish,  and  material  specifications. 
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3D  PDF  Solution  Costs 


The  OEM,  program  office,  or  ESA  can  acquire  and  maintain  the  3D  PDF  conver¬ 
sion  software. 

Developing  3D  PDF  Template  (Requirement  4) 

For  all  of  the  3D  PDF  software  solutions,  a  template  that  defines  the  format  of  the 
3D  PDF  output  file  must  be  created,  and  it  must  include  all  of  the  required  data 
elements  (Appendix  A).  We  did  not  have  the  time  or  resources  to  build  a  3D  PDF 
template  from  scratch,  so  we  collected  estimates  of  the  time  required  to  build  a 
template  from  subject  matter  experts  (SMEs)  at  two  private  companies — Dassault 
and  Anark — and  two  ESAs — U.S.  Army  Armament  Research,  Development  and 
Engineering  Center  and  Warner  Robins  Air  Fogistics  Complex — who  have  built 
these  templates. 

The  OEM,  program  office,  or  ESA  can  create  a  3D  PDF  template.  The 
development  time  for  a  template  depends  on  the  programmer’s  experience.  On 
average,  it  takes  about  160-320  hours  to  build  a  3D  PDF  template  that  includes 
all  of  the  sustainment  data  requirements  and  verify  the  output  file.  Building  a 
template  is  a  one-time  nonrecurring  task  for  the  entity  (OEM,  program  office,  or 
ESA)  charged  with  producing  3D  PDF  files,  so  the  cost  is  relatively  low  and 
easily  calculated  as  the  product  of  the  hours  to  build  and  verify  the  template  and 
the  labor  rate  for  those  involved  in  that  activity.  For  example,  if  the  labor  rate  is 
$115  per  hour,  the  cost  to  develop  a  PDF  template  varies  between  about  $18,000 
and  $37,000. 

Converting  Native  CAD  Files  to  3D  PDFs  (Requirement  5) 

The  OEM,  program  office,  or  ESA  can  convert  native  CAD  files  to  3D  PDF  files, 
an  activity  that  is  basically  a  “button  push.”  Once  the  native  files  have  been  cre¬ 
ated  with  all  the  requisite  data  in  an  annotated  format  and  the  3D  PDF  template 
has  been  created,  virtually  no  labor  is  required  beyond  selecting  the  native  CAD 
file  and  starting  the  conversion  process.  (At  the  very  most,  an  engineer  might 
spend  5  minutes  selecting  a  model  and  then  starting  the  conversion  process.)  If  the 
activity  has  many  files  to  convert  and  has  acquired  a  3D  PDF  server  solution,  it 
can  batch  process  these  files  without  any  human  intervention. 

Once  the  3D  PDF  output  file  is  created,  it  should  be  validated  manually  or  with 
the  aid  of  validation  software  by  the  OEM,  program  office,  or  ESA.  To  obtain  an 
estimate  of  the  labor  hours  required  to  manually  validate  3D  PDF  files,  we 
consulted  with  an  Air  Force  ESA  at  Warner  Robins  that  is  performing  such 
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validations  for  a  variety  of  model/file  complexities.4  Table  4-4  shows  the 
estimated  time  in  hours  for  manually  validating  3D  PDF  files. 


Table  4-4.  Time  Required  to  Manually  Validate  One  3D  PDF  File  (Hours) 


Part  complexity 

Simple 

Medium 

Complex 

Super  complex 

2-3 

4-6 

10-12 

30-40 

Assuming  a  labor  rate  of  $1 15  per  hour,  the  cost  to  manually  validate  a  single  3D 
PDF  file  ranges  from  about  $230  to  $4,600,  depending  on  the  file  complexity. 

We  obtained  a  copy  of  the  3D  PDF  validation  software,  CADIQ,  developed  by 
International  TechneGroup  Incorporated  (ITI)  to  examine  as  an  alternative  to 
manually  validating  3D  PDF  files.  The  CADIQ  output  identifies  any  deviations 
between  the  3D  PDF  file  and  native  CAD  file  used  as  the  source  file.  We 
exercised  the  software  by  validating  3D  PDF  files  (of  varying  complexities)5 
against  the  original  model/file  to  assess  CADIQ  capabilities  and  measure  the  time 
required  to  perform  a  validation.  We  also  obtained  validation  time  estimates  from 
an  SME  at  ITI.  The  ITI  SME  estimates  were  consistent  with  our  exercise  results. 
Table  4-5  shows  the  estimated  time,  in  minutes,  for  validating  a  3D  PDF  file 
using  the  CADIQ  automated  software. 

Table  4-5.  Time  Required  to  Validate  One  3D  PDF  File 
Using  CADIQ  (Minutes) 


Model/file  complexity 

Simple 

Medium 

Complex 

19 

24 

33 

Assuming  a  labor  rate  of  $1 15  per  hour,  the  cost  to  validate  a  single  3D  PDF  file 
using  CADIQ  software  ranges  from  about  $36  to  $63,  depending  on  the  file 
complexity. 


4  A  simple  model/file  applies  to  a  basic  item  (such  as  a  shaft,  washer,  or  handle)  documented 
as  a  one-page  2D  drawing.  One  of  medium  complexity  applies  to  a  piece  part  or  simple  assembly 
with  several  parts,  documented  as  a  two-  or  three -page  2D  drawing.  A  complex  model/file  applies 
to  a  part  or  assembly  with  many  parts  requiring  4  to  10  2D  drawings.  A  super  complex  model/file 
applies  to  a  complex  part  with  multiple  assemblies  requiring  more  than  10  2D  drawings. 

5  ITI  classifies  model/file  complexity  on  the  basis  of  number  of  resident  features  (shaft, 
washer,  or  handle,  for  example)  in  a  model.  A  simple  model  has  less  than  10  features;  a  medium 
model  has  more  than  10,  but  less  than  25;  and  a  complex  model  has  more  than  25. 
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3D  PDF  Solution  Costs 


Cost  of  CAD  IQ  Software 

The  CADIQ  software  package  can  be  purchased  as  a  workstation  bundle  or  a  mul¬ 
tiprocessor  server  bundle.  The  former  costs  about  $27,000  and  includes  one  li¬ 
cense  (the  cost  assumes  the  user  is  validating  models  that  contain  PMI);  the 
software  can  be  installed  on  many  workstations.  The  latter  costs  about  $87,000 
and  includes  two  licenses  for  a  server  (the  cost  assumes  the  user  is  validating 
models  that  contain  PMI);  the  software  can  be  installed  on  many  workstations. 

The  advantage  of  the  latter  (the  server  solution)  is  that  it  can  mn  multiple  valida¬ 
tions  at  the  same  time  (perform  batch  processing).  The  annual  maintenance  cost 
for  the  workstation  bundle  is  about  $5,400;  for  the  multiprocessor  bundle,  it  is 
about  $17,400. 

Producing  STEP  Files  (Requirement  6) 

Each  model  represented  in  a  3D  PDF  file  must  have  a  corresponding  validated 
STEP  file  (AP203  format).  The  STEP  file  is  necessary  to  provide  the  geometry  to 
create  the  numerical  control  (NC)  code  for  the  NC  machines  used  to  manufacture 
a  part.  As  with  producing  a  3D  PDF  file,  virtually  no  labor  is  required  to  create  a 
STEP  file  beyond  selecting  the  native  CAD  file  and  starting  the  conversion  pro¬ 
cess.  (At  most,  an  engineer  might  spend  5  minutes  selecting  a  model  and  then 
starting  the  conversion  process.)  All  major  CAD  platforms  have  a  built-in  capabil¬ 
ity  to  create  and  export  a  STEP  file.  The  OEM,  program  office,  or  ESA  can  create 
a  STEP  file. 

Like  a  3D  PDF  file,  the  STEP  file  also  requires  validation.  Because  the  STEP  file 
is  not  in  human-readable  format,  software  validation  programs  are  used  to  per¬ 
form  the  validation.  One  such  program  is  the  previously  mentioned  CADIQ,  de¬ 
veloped  by  ITI.  We  exercised  the  software  by  validating  STEP  files  (of  varying 
complexities)  against  the  original  model  to  assess  CADIQ  capabilities  and  meas¬ 
ure  the  time  required  to  perform  a  validation.  We  also  obtained  validation  time  es¬ 
timates  from  an  ITI  SME,  whose  estimates  were  consistent  with  our  exercise 
results.  In  addition  to  exercising  the  CADIQ  software  and  obtaining  ITI  SME  esti¬ 
mates,  we  engaged  the  NAVAIR  ESA  at  Lakehurst,  which  was  performing  STEP 
file  validations  using  CADIQ.  It  reported  the  average  time  to  validate  a  STEP  file 
as  about  15-20  minutes,  consistent  with  our  results  and  the  ITI  SME  estimates. 
Table  4-6  shows  the  estimated  time,  in  minutes,  for  validating  a  STEP  file. 

Table  4-6.  Time  Required  to  Validate  One  STEP  File 
Using  CADIQ  (Minutes) 


Part  complexity 

Simple 

Medium 

Complex 

17 

24 

35 
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The  OEM,  program  office,  or  ESA  can  validate  a  STEP  file.  Assuming  a  labor 
rate  of  $1 15  per  hour,  the  cost  to  validate  a  single  STEP  file  using  CADIQ  soft¬ 
ware  ranges  from  about  $33  to  $67,  depending  on  the  file  complexity. 

As  noted,  the  time  to  validate  STEP  files  using  CADIQ  software  is  relatively 
consistent.  On  the  other  hand,  the  time  to  correct  validation  errors  discovered 
using  CADIQ  varies  greatly,  depending  on  the  specific  issue  and  number  of 
errors.  Accordingly,  furnishing  a  standardized  estimate  for  correcting  validation 
errors  is  impossible. 

Once  the  3D  PDF  file  and  associated  STEP  files  have  been  validated,  they  must 
be  transferred  to  DLA  or  the  appropriate  service  sustainment  activity  for  use  as 
the  data  of  record  in  the  competitive  solicitation  technical  data  package.  No 
additional  labor  or  cost  is  associated  with  this  action  because  the  same  process 
used  to  transfer  2D  drawings  is  used  for  the  transfer  of  3D  technical  data.  For 
example,  the  ESA  posts  the  3D  PDF  file  and  STEP  file  to  JEDMICS,  and  the 
DLA  product  data  specialist  accesses  JEDMICS  and  retrieves  the  files,  which  are 
then  stored  in  DLA  information  technology  systems  pending  development  and 
issuance  of  a  solicitation  as  part  of  the  procurement  process. 


Summary 


In  the  preceding  subsections,  we  identify  and  characterize  the  minimum 
requirements  or  actions  necessary  for  a  program  office  to  implement  a  3D  PDF 
solution  to  support  the  sustainment  process.  We  also  specify  the  associated  labor 
hours  or  costs  for  each  requirement.  As  noted,  the  specific  costs  vary  from 
program  to  program,  depending  on  the  number  of  models  or  files  that  require 
annotation,  conversion,  and  validation.  The  labor  rate  assumed  drives  the  final 
cost. 

To  assist  DLA,  PMA-261,  and  other  program  offices,  we  compiled  all  of  the  data 
elements  for  each  requirement  and  its  associated  labor  hours  and  costs  into  a  cost 
analysis  tool  that  can  be  used  to  calculate  the  basic  and  expected  annual 
maintenance  costs  of  implementing  a  3D  PDF  solution.  We  include  the  tool,  an 
Excel  spreadsheet,  as  an  addendum  to  this  report.  We  used  it  to  conduct  a  notional 
BCA  for  implementing  a  3D  PDF  solution  for  the  CH-53K  program. 

Notional  BCA  for  3D  PDF  Solution 


PMA-261  and  DLA  are  concerned  about  the  cost  of  implementing  a  3D  PDF  so¬ 
lution  for  the  CH-53K  Program.  The  OEM  told  PMA-261  it  would  cost  an  esti¬ 
mated  $10  million  to  convert  the  current  3D  CATIA-based  technical  data  “to 
another,  less  costly  ‘viewable’  software  program.”  PMA-261  and  DLA  agree  that 
the  estimated  cost  is  significant,  but  neither  activity  has  a  ready  means  to  assess 
the  validity  of  the  OEM  estimate. 
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3D  PDF  Solution  Costs 


In  addition,  PMA-261  does  not  know  specifically  what  the  OEM  estimate  covers 
(for  example,  the  cost  of  populating  native  files  with  required  sustainment  data  el¬ 
ements,  cost  of  annotating  all  CH-53K  parts  or  only  CH-53K  parts  subject  to 
competition,  or  cost  of  conversion  software).  Neither  does  PMA-261  yet  know 
how  many  or  what  type  of  CH-53K  parts  will  be  subject  to  competitive  procure¬ 
ment  during  the  system  life-cycle  operations  and  sustainment  phase.  This  latter 
fact  precludes  the  development  of  an  accurate  BCA  to  corroborate  or  refute  the 
OEM’s  $10  million  estimate. 

Nevertheless,  we  can  furnish  useful  cost  information  and  a  cost  analysis  tool  (the 
Excel  spreadsheet)  as  part  of  a  notional  BCA.  The  cost  information  and  the  tool 
can  be  easily  updated  and  exercised  to  provide  any  program  a  creditable  BCA  as 
the  program  matures  and  accurate  counts  become  available  for  the  number  and 
type  or  complexity  of  parts  expected  to  be  competitively  procured. 

Input  Data  for  Notional  BCA 

This  subsection  describes  the  specific  input  data  used  for  the  notional  BCA.  The 
data  are  based  on  the  cost  and  labor  figures  associated  with  each  of  the  six 
requirements  for  implementing  a  3D  PDF  solution,  as  previously  discussed. 

Cost  to  Develop  Native  CAD  Files 

Three  data  elements  are  associated  with  the  cost  of  developing  native  CAD  files 
with  the  minimum  data  requirements  for  sustainment  (Appendix  A): 

1.  Number  of  models  to  develop.  We  assigned  a  value  of  0  because  the 
CH-53K  contract  already  requires  delivery  of  this  information. 

2.  Number  of  labor  hours  required  to  develop  a  model.  We  assigned  a  value 
of  0  because  the  CH-53K  contract  already  requires  delivery  of  this 
information. 

3.  Labor  rate  for  developing  the  models.  We  assigned  a  value  of  0  because 
the  CH-53K  contract  already  requires  delivery  of  this  information. 

Cost  to  Annotate  Native  CAD  Files 

Four  data  elements  are  associated  with  the  cost  of  annotating  dimensions, 
tolerances,  datum,  and  procurement  metadata  in  a  native  CAD  file: 

1.  Number  of  models  to  annotate.  We  assigned  a  value  of  10,000  as  an  esti¬ 
mate  for  the  notional  BCA  because  the  current  EDFP  models  were  not  an¬ 
notated  when  they  were  developed. 

2.  Average  number  of  annotations  per  model.  We  assigned  a  value  of  49, 
which  is  the  average  number  of  annotations  required  for  the  10  EDFP 
models  we  assessed. 
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3.  Number  of  labor  hours  required  to  annotate  a  model.  We  assigned  a  value 
of  0.05  hour  (3  minutes)  as  calculated  earlier  in  this  chapter. 

4.  Labor  rate  for  annotating  the  models.  We  assigned  a  value  of  $1 15  per 
hour  as  a  conservative  estimate  for  the  notional  BCA.6 

Cost  to  Acquire  3D  PDF  Conversion  Software 

One  data  element — the  cost  of  conversion  software — is  associated  with  the  cost  of 
acquiring  3D  PDF  conversion  software.  We  assigned  a  value  of  $115,000;  this  is 
the  cost  previously  identified  for  the  Anark  Core  Workstation  server  solution  and 
represents  a  conservative  estimate  for  the  notional  BCA. 

Annual  Maintenance  Cost  for  3D  PDF  Conversion  Software 

One  data  element — the  annual  cost  of  maintaining  conversion  software — is 
associated  with  the  cost  of  maintaining  the  3D  PDF  conversion  software.  We 
assigned  a  value  of  $29,000;  this  is  the  cost  previously  identified  for  the  Anark 
Core  Workstation  server  solution  and  represents  a  conservative  estimate  for  the 
notional  BCA. 

Cost  to  Create  3D  PDF  T emplate 

Two  data  elements  are  associated  with  the  cost  of  creating  a  3D  PDF  template: 

1.  Number  of  labor  hours  required  to  create  a  template.  We  assigned  a  value 
of  320  hours  as  identified  earlier  in  this  chapter.  This  represents  a  con¬ 
servative  estimate  for  the  notional  BCA. 

2.  Labor  rate  for  creating  the  template.  We  assigned  a  value  of  $1 15  per 
hour  as  a  conservative  estimate  for  the  notional  BCA. 

Cost  to  Convert  Native  CAD  Files  to  3D  PDF  Files 

Three  data  elements  are  associated  with  the  cost  of  converting  native  CAD  files  to 
3D  PDF  files  using  the  template: 

1.  Number  of  models  to  convert.  We  assigned  a  value  of  10,000  as  a  con¬ 
servative  estimate  for  the  notional  BCA. 

2.  Number  of  labor  hours  required  to  convert  a  model.  We  assigned  a  value 
of  0.08  hour  (5  minutes)  as  calculated  earlier  in  this  chapter. 

3.  Labor  rate  for  converting  the  files.  We  assigned  a  value  of  $1 15  per  hour 
as  a  conservative  estimate  for  the  notional  BCA. 


6  See  Note  2,  this  chapter. 
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Cost  to  Manually  Validate  3D  PDF  Files 

Nine  data  elements  are  associated  with  the  cost  of  manually  validating  the  3D 
PDF  files  created  using  the  template: 

1.  Number  of  simple  models  that  require  validation.  We  assigned  a  value  of 
0  because  we  chose  to  use  automated  validation  software  in  lieu  of  manu¬ 
ally  evaluating  the  files. 

2.  Number  of  medium  complexity  models  that  require  validation.  We  as¬ 
signed  a  value  of  0  because  we  chose  to  use  automated  validation  software 
in  lieu  of  manually  evaluating  the  files. 

3.  Number  of  complex  models  that  require  validation.  We  assigned  a  value  of 
0  because  we  chose  to  use  automated  validation  software  in  lieu  of  manu¬ 
ally  evaluating  the  files. 

4.  Number  of  super  complex  models  that  require  validation.  We  assigned  a 
value  of  0  because  we  chose  to  use  automated  validation  software  in  lieu 
of  manually  evaluating  the  files. 

5.  Number  of  labor  hours  required  to  manually  validate  a  simple  3D  PDF 
file.  We  assigned  a  value  of  3  hours  as  identified  earlier  in  this  chapter. 

6.  Number  of  labor  hours  required  to  manually  validate  a  medium  complex¬ 
ity  3D  PDF  file.  We  assigned  a  value  of  6  hours  as  identified  earlier  in  this 
chapter. 

7.  Number  of  labor  hours  required  to  manually  validate  a  complex  3D  PDF 
file.  We  assigned  a  value  of  12  hours  as  identified  earlier  in  this  chapter. 

8.  Number  of  labor  hours  required  to  manually  validate  a  super  complex  3D 
PDF  file.  We  assigned  a  value  of  40  hours  as  identified  earlier  in  this 
chapter. 

9.  Labor  rate  for  validating  the  models.  We  assigned  a  value  of  $1 15  per 
hour  as  a  conservative  estimate  for  the  notional  BCA. 

Cost  to  Validate  3D  PDF  Files  Using  Automated  Software 

Nine  data  elements  are  associated  with  the  cost  of  validating  the  3D  PDF  files 
using  automated  software: 

1.  Cost  to  acquire  validation  software.  We  assigned  a  value  of  $87,000;  this 
is  the  cost  previously  identified  for  the  CADIQ  software  and  represents  a 
conservative  estimate  for  the  notional  BCA. 
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2.  Annual  cost  of  maintaining  automated  validation  software.  We  assigned  a 
value  of  $17,400;  this  is  the  cost  previously  identified  for  the  CADIQ  soft¬ 
ware  and  represents  a  conservative  estimate  for  the  notional  BCA. 

3.  Number  of  simple  models  that  require  validation.  We  assigned  a  value  of 
3,000,  which  represents  30  percent  of  the  total  10,000  models  requiring 
validation. 

4.  Number  of  medium  complexity  models  that  require  validation.  We  as¬ 
signed  a  value  of  4,500,  which  represents  45  percent  of  the  total 
10,000  models  requiring  validation. 

5.  Number  of  complex  models  that  require  validation.  We  assigned  a  value  of 
2,500,  which  represents  25  percent  of  the  total  10,000  models  requiring 
validation. 

6.  Number  of  labor  hours  required  to  validate  a  simple  3D  PDF  file  using 
CADIQ.  We  assigned  a  value  of  0.32  hour  (19.2  minutes)  as  identified  ear¬ 
lier  in  this  chapter. 

7.  Number  of  labor  hours  required  to  validate  a  medium  complexity  3D  PDF 
file  using  CADIQ.  We  assigned  a  value  of  0.4  hour  (24  minutes)  as  identi¬ 
fied  earlier  in  this  chapter. 

8.  Number  of  labor  hours  required  to  validate  a  complex  3D  PDF  file  using 
CADIQ.  We  assigned  a  value  of  0.55  hour  (33  minutes)  as  identified  ear¬ 
lier  in  this  chapter. 

9.  Labor  rate  for  validating  the  3D  PDF  files  using  CADIQ.  We  assigned  a 
value  of  $1 15  per  hour  as  a  conservative  estimate  for  the  notional  BCA. 

Cost  to  Convert  Native  CAD  Files  to  STEP  (AP203)  Files 

Three  data  elements  are  associated  with  the  cost  of  converting  native  CAD  files  to 
STEP  (AP203)  files  using  the  native  CAD  software  utilities: 

1.  Number  of  models  to  convert.  We  assigned  a  value  of  10,000  as  an  esti¬ 
mate  for  the  notional  BCA. 

2.  Number  of  labor  hours  required  to  convert  a  model.  We  assigned  a  value 
of  0.08  hours  (5  minutes)  as  calculated  earlier  in  this  chapter. 

3.  Labor  rate  for  populating  the  models.  We  assigned  a  value  of  $1 15  per 
hour  as  a  conservative  estimate  for  the  notional  BCA. 
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Cost  to  Validate  STEP  Files  Using  Automated  Software 

Nine  data  elements  are  associated  with  the  cost  of  validating  the  3D  PDF  files 
using  automated  software: 

1.  Cost  to  acquire  validation  software.  We  assigned  a  value  of  $0  because 
we  are  using  CADIQ  for  the  STEP  file  validations  and  we  have  already 
accounted  for  the  acquisition  cost  of  the  software  under  the  3D  PDF  file 
validation  data  element. 

2.  Annual  cost  of  maintaining  automated  validation  software.  We  assigned  a 
value  of  $0  because  we  are  using  CADIQ  for  the  STEP  file  validations 
and  we  have  already  accounted  for  the  acquisition  cost  of  the  software  un¬ 
der  the  3D  PDF  file  validation  data  element. 

3.  Number  of  simple  models  that  require  validation.  We  assigned  a  value  of 
3000,  which  represents  30  percent  of  the  total  10,000  models  requiring 
validation. 

4.  Number  of  medium  complexity  models  that  require  validation.  We 
assigned  a  value  of  4,500,  which  represents  45  percent  of  the  total 
10,000  models  requiring  validation. 

5.  Number  of  complex  models  that  require  validation.  We  assigned  a  value  of 
2,500,  which  represents  25  percent  of  the  total  10,000  models  requiring 
validation. 

6.  Number  of  labor  hours  required  to  validate  a  simple  STEP  file  using 
CADIQ.  We  assigned  a  value  of  0.28  hours  (16.8  minutes)  as  identified 
earlier  in  this  chapter. 

7.  Number  of  labor  hours  required  to  validate  a  medium  complexity  STEP 
file  using  CADIQ.  We  assigned  a  value  of  0.4  hours  (24  minutes)  as  iden¬ 
tified  earlier  in  this  chapter. 

8.  Number  of  labor  hours  required  to  validate  a  complex  STEP  file  using 
CADIQ.  We  assigned  a  value  of  0.58  hours  (34.8  minutes)  as  identified 
earlier  in  this  chapter. 

9.  Labor  rate  for  validating  the  STEP  files  using  CADIQ.  We  assigned  a 
value  of  $1 15  per  hour  as  a  conservative  estimate  for  the  notional  BCA. 

We  took  each  of  the  data  elements  identified  above,  including  the  assigned  input 
values,  and  incorporated  them  into  an  Excel  spreadsheet,  complete  with  appropri¬ 
ate  formulas,  to  calculate  the  cost  of  implementing  each  requirement  and  the  total 
cost  of  implementing  a  3D  PDF  solution  for  the  CH-53K  program.  We  describe 
the  results  in  the  next  subsection. 
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Notional  Cost  of  Implementing  3D  PDF  Solution  for  CH-53K 

This  subsection  identifies  the  specific  costs  associated  with  each  of  the  individual 
requirements  for  implementing  a  3D  PDF  solution  and  the  notional  total  cost  of 
implementing  that  solution  for  the  CH-53K.  As  discussed  earlier,  this  is  a  notional 
BCA  because  we  do  not  know  how  many  or  what  type  of  CH-53K  parts  will  be 
subject  to  competitive  procurement  during  the  system  life-cycle  operations  and 
sustainment  phase.  Therefore,  our  estimates  regarding  the  number  of  models  for 
those  parts  and  complexity  of  those  models  is  purely  a  guess. 

Table  4-7  shows  the  results  of  exercising  the  cost  analysis  tool  (an  addendum  to 
this  report)  using  the  input  data  described  in  the  previous  section.  Implementation 
requirement  numbers  (1,  2,  3,  4,  etc.)  are  keyed  to  corresponding  numbers  in  the 
cost  analysis  tool. 

Table  4-7.  Notional  Cost  of  Implementing  a  3D  PDF  Solution  for  CH-53K  ($) 


Implementation  requirement 

Cost 

Annual 

maintenance 

cost 

1 .  Develop  Native  CAD  files  with  minimum  data  require¬ 
ments  for  sustainment 

0 

NA 

2.  Annotate  dimensions,  tolerances,  datum,  and  procure¬ 
ment  metadata  in  native  CAD  models 

2,817,500 

NA 

3.  Acquire  3D  PDF  conversion  software 

115,000 

NA 

4.  Support  3D  PDF  conversion  software 

NA 

29,000 

5.  Create  3D  PDF  template 

36,800 

NA 

6.  Convert  native  CAD  files  to  3D  PDF  (PRC)  document 
using  3D  PDF  template 

95,883 

NA 

7.  Validate  each  3D  PDF  document  using  automated 
software 

561,375 

17,400 

8.  Produce  STEP  (AP203)  file  corresponding  to  each  3D 

PDF  file 

95,833 

NA 

9.  Validate  each  STEP  file  using  automated  software 

472,458 

NA 

Total 

4,194,800 

46,400 

Note:  NA  =  not  applicable. 


Based  on  our  notional  BCA,  the  cost  for  implementing  a  3D  PDF  solution  for  the 
CH-53K  program  is  about  $4.2  million,  plus  annual  software  maintenance  costs 
of  about  $46,000.  This  is  significantly  less  than  the  $10  million  OEM  estimate, 
but,  as  previously  noted,  directly  comparing  these  figures  is  inappropriate  until 
PMA-261  better  understands  the  basis  for  the  OEM  estimate. 

Clearly,  the  largest  component  of  the  notional  BCA  cost  is  the  $2.8  million  cost  to 
annotate  the  dimensions,  tolerances,  datum,  and  procurement  metadata  in  native 
CAD  models.  For  the  notional  BCA,  we  assumed  this  action  took  place  after  the 
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models  were  originally  created;  that  is,  a  design  engineer  went  back  into  an  exist¬ 
ing  model  and  annotated  it.  We  estimate  that,  if  the  CH-53K  models  were  anno¬ 
tated  as  part  of  the  original  model  development/creation  process,  the  time  to 
perform  an  annotation  would  be  about  50  percent  (about  1.5  minutes)  of  the  time 
required  to  annotate  a  model  after  it  has  been  created,  which  we  estimated  at  3 
minutes.  The  time  difference  is  a  result  of  the  design  engineer’s  having  all  the 
pertinent  information  upfront  during  the  design  process  rather  than  having  to  pull 
data  from  a  variety  of  different  files,  after  the  fact.  If  the  models  had  been  anno¬ 
tated  at  the  time  they  were  created,  we  estimate  that  the  cost  to  implement  a  3D 
PDF  solution  for  our  notional  BCA  would  have  been  reduced  by  about  $1.4  mil¬ 
lion,  saving  roughly  33  percent  of  the  overall  cost. 

If  PMA-261  can  obtain  a  valid  estimate  of  the  number  of  models  required  for  the 
parts  to  be  competitively  procured  and  their  complexity,  it  can  adjust  the  appro¬ 
priate  data  elements  in  the  cost  analysis  tool  and  recalculate  the  total  cost  to  im¬ 
plement  a  3D  PDF  solution.  Depending  on  the  costs,  it  can  then  decide  which  of 
the  implementing  requirements  the  OEM  should  accomplish  and  which  PMA-261 
or  the  program’s  designated  ESA  should  accomplish. 
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Chapter  5 

Conclusions 


We  formed  three  principal  conclusions  from  our  discussions  with  NAVSUP,  LIS, 
and  PMA-261  regarding  development  of  a  practicable  solution  for  providing  3D 
technical  data  to  support  the  provisioning  and  cataloging  processes: 

1.  The  3D  PDF  file  format  is  the  best  solution  for  providing  CH-53K  3D 
technical  data  to  NAVSUP  and  LIS  to  support  the  provisioning  and  cata¬ 
loging  processes.  Implementing  this  solution  is  also  consistent  with  the  so¬ 
lution  that  CH-53K  has  endorsed  for  solving  a  similar  problem  for 
sustainment.  Although  PMA-261  agrees  with  this  solution,  it  currently 
does  not  have  funds  to  implement  it.  PMA-261  is  working  with  the 
NAVAIR  enterprise  to  identify  a  funding  source;  the  outcome  is  to  be 
determined. 

2.  The  overall  provisioning  and  cataloging  processes  do  not  need  to  change 
to  accommodate  the  use  of  3D  technical  data  if  the  data  are  provided  as  a 
3D  PDF  file.  The  use  of  3D  PDF  files  as  the  documentation  medium  for 
3D  technical  data  will  not  require  NAVSUP  or  LIS  to  purchase  any  addi¬ 
tional  software  or  execute  extensive  training. 

3.  The  CH-53K  technical  data  issue  relative  to  supporting  the  provisioning 
and  cataloging  processes  is  not  unique.  A  number  of  weapon  system  pro¬ 
grams  that  started  in  the  early  2000s  plan  to  use  3D  technical  data  as  part 
of  a  model-based  enterprise  approach  throughout  the  system’s  life  cycle. 
However,  detailed  guidance  regarding  3D  data  completeness  and  format 
requirements  is  lacking.  In  general,  the  system  designers  who  develop  the 
native  CAD  files — which  should  be  the  basis  for  all  follow-on  manufac¬ 
turing,  provisioning,  cataloging,  and  sustainment  activities — rarely  include 
(or  even  consider)  the  requirements  for  these  activities  in  the  baseline  3D 
models.  As  development  of  these  other  weapon  systems  continues,  more 
instances  of  3D  technical  data  that  cannot  meet  the  requirements  to  sup¬ 
port  the  provisioning  and  cataloging  processes  will  arise. 
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Chapter  6 

Recommendations 


On  the  basis  of  our  findings  (Chapters  2  through  4)  and  conclusions  (Chapter  5), 
we  recommend  that  DLA,  NAVSUP,  PMA-261,  and  NAVAIR  take  a  series  of 
actions  to  ensure  DLA’s  capability  to  provision  and  catalog  CH-53K  parts  using 
3D  technical  data  provided  by  the  program  office: 

♦  DLA 

>  Along  with  NAVSUP,  continue  a  regular  dialog  with  PMA-261  and 
monitor  contract  efforts  and  the  program’s  ability  to  implement  a  3D 
PDF  solution  for  provisioning  and  cataloging,  including  conduct  of  a 
proposed  Navy  MANTECH1  project  to  demonstrate  executing  a  3D 
PDF  solution  amongst  the  CH53K  program,  NAVSUP,  and  DLA. 

>  Continue  to  engage  with  select  working  groups — DoD  3D  PDF  Work¬ 
ing  Group,  Military  Standard  31000,  American  Society  of  Mechanical 
Engineer  (ASME)  Y14  Working  Group,  DoD  Engineering  Drawing 
and  Modeling  Working  Group,  and  the  Digital  Manufacturing  and  De¬ 
sign  Innovation  Institute — to  review  and  update  technical  data  policy 
to  specifically  address  requirements  for  3D  technical  data  formats. 

>  Identify  and  characterize  other  military  service  programs  that  will  de¬ 
liver  3D  technical  data  to  LIS  in  the  next  5  years  and  identify  appropri¬ 
ate  solutions  if  a  3D  PDF  method  cannot  be  implemented. 

>  Officially  adopt  a  3D  PDF  solution  as  the  desired  delivery  medium  of 
3D  technical  data  from  the  services  and  conduct  an  outreach  program 
to  publicize  that  decision. 

♦  NAVSUP 

>  Along  with  DLA,  continue  a  regular  dialog  with  PMA-261  and 
monitor  contract  efforts  and  the  program’s  ability  to  implement  a  3D 
PDF  solution  for  provisioning  and  cataloging. 

>  Identify  and  characterize  other  Navy  programs  that  will  deliver  3D 
technical  data  for  provisioning  in  the  next  5  years  and  identify  appro¬ 
priate  solutions  if  a  3D  PDF  method  cannot  be  implemented. 


1  MANTECH  is  abbreviated  terminology  for  DoD  Manufacturing  Technology  Program. 
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>  Officially  adopt  the  3D  PDF  solution  as  the  desired  delivery  medium 
of  3D  technical  data  from  Navy  programs  and  conduct  an  outreach 
program  to  publicize  that  decision. 

♦  PMA-261.  Engage  NAVAIR  management  and  seek  assistance  in  procur¬ 
ing  funding  to  support  a  3D  PDF  enterprise  solution  for  providing 
NAVSUP  and  LIS  with  CH-53K  technical  data  to  support  the  provisioning 
and  cataloging  processes. 

♦  NAVAIR.  If  the  enterprise  is  unable  to  fund  or  implement  a  3D  PDF 
solution  for  the  CH-53K  program,  have  PMA-261  engage  DLA  and 
NAVSUP  to  develop  an  acceptable  alternative  solution  for  providing 
usable  technical  data  to  support  the  provisioning  and  cataloging  processes. 

♦  Other  program  offices 

>  Review  program  technical  data  deliverables  and  determine  whether 
they  meet  the  DLA  characteristics  and  data  requirements  identified  in 
Appendix  A. 

>  If  the  program  intends  to  receive  and  use  3D  (rather  than  2D)  technical 
data,  consider  implementing  a  3D  PDF  file  solution  as  the  delivery 
format  to  support  the  provisioning,  cataloging,  and  sustainment 
processes. 


6-2 


Appendix  A 

Requisite  Technical  Data  for  Procurement 


We  interviewed  personnel  who  use  technical  data  in  their  daily  activities  at  each 
of  the  DLA  supply  chains — Troop  Support,  Land  and  Maritime,  and  Aviation.  We 
asked  them  to  identify  specific  information  and  information  attributes  they  need 
and  use  to  build  a  technical  data  package  for  inclusion  in  a  procurement  bid  set. 

They  identified  the  following  data  elements  and  attributes  as  the  minimum 
required  data  to  support  the  procurement  process,  which  are  the  same  as  those 
required  in  the  provisioning  and  cataloging  processes  (in  alphabetical  order): 

♦  Callouts.  Additional  documents  necessary  as  references  or  to  further  de¬ 
fine  the  item. 

♦  Classification  (mandatory  when  applicable).  The  classification  of  the  doc¬ 
ument  when  applicable  (Top  Secret,  Secret,  or  Confidential). 

♦  Commercial  and  Government  Entity  (CAGE)  code  (mandatory).  A  five- 
character  code,  listed  in  Cataloging  Handbook  H4/H8,  assigned  to  com¬ 
mercial  and  government  activities  that  manufacture  or  develop  items,  or 
provide  services  or  supplies  for  the  government.  When  used  with  a  draw¬ 
ing  number  or  part  number,  the  CAGE  code  designates  the  design  activity 
from  whose  series  the  drawing  or  part  number  is  assigned.  The  CAGE 
code  was  previously  called  “manufacturers  code,”  or  “Federal  Supply 
Code  for  Manufacturers”  (ASME  Y  14.24M).  For  the  commercial  sector, 
where  there  is  no  requirement  for  the  CAGE  code,  the  block  may  be 
eliminated. 

♦  Completeness.  Completeness  and  accuracy  of  the  data  in  describing  the 
design;  subassemblies;  component  parts;  materials;  special  processes;  crit¬ 
ical,  major,  and  minor  characteristics;  functional  specification;  tolerances; 
and  scale  in  adequate  detail  to  fully  define  the  item  being  produced. 

♦  Control  code.  Metadata  field  indicating  the  two  alpha  activity  code  of  the 
design  activity. 

♦  Dimensions  ( mandatory ).  A  numerical  value  expressed  in  appropriate 
units  of  measure  and  indicated  on  a  drawing  and  in  other  documents — 
along  with  lines,  symbols,  and  notes — to  define  the  size  or  geometric  char¬ 
acteristic,  or  both,  of  a  part  or  part  feature. 


A-l 


♦  Document  approval  (mandatory).  The  design  activity  verification  that  the 
engineering  drawings  and  associated  lists  are  technically  accurate,  in  con¬ 
formance  with  all  requirements,  and  have  been  approved.  Approval  is  sig¬ 
nified  in  the  signature  block  on  the  original  by  signature  or  approval 
indicator  established  by  the  design  activity.  An  approval  indicator  may  be 
any  symbol  adopted  by  the  design  activity.  A  signature  or  approval  indica¬ 
tor  may  be  either  handwritten  or  electronically  affixed  as  long  as  it  is 
unique  to  an  individual,  capable  of  verification,  and  under  the  individual’s 
sole  control. 

♦  Document  data  code.  A  code  within  the  metadata  that  further  defines  the 
document  type  (detailed  drawing,  vendor  item  control,  parts  list,  applica¬ 
tion  list,  etc.). 

♦  Document  number.  Letters,  numbers,  or  a  combination  of  letters  and  num¬ 
bers,  which  may  or  may  not  be  separated  by  dashes.  The  number  assigned 
to  a  particular  drawing  and  the  CAGE  code  provide  a  unique  drawing 
identification.  The  drawing  number  is  assigned  from  numbers  controlled 
by  the  design  activity  whose  CAGE  code  is  assigned  to  the  drawing. 

♦  Document  title.  The  name  by  which  the  part  or  item  will  be  known,  con¬ 
sisting  of  a  basic  item  name,  government  type  designator,  if  applicable, 
and  sufficient  used  trademarked  names  and  the  words  ASSEMBLY 
(ASSY),  SUBASSEMBLY  (SUBASSY),  or  INSTALLATION  (ENSTL). 
Abbreviations  may  be  used  in  the  second  part  of  the  title.  ASME  Y14.38 
lists  approved  abbreviations,  but  in  general,  their  use  should  be  avoided. 

♦  Expiration  date.  The  date  by  which  a  technical  data  package  must  be  re¬ 
viewed  and  revalidated. 

♦  Export  control  (mandatory).  A  restriction  that  regulates  the  export  of  data, 
software,  or  materials  outside  the  United  States  to  protect  against  the  re¬ 
lease  of  critical  technology. 

♦  Finishes.  Data  requirements  that  describe  the  nature  of  a  surface  finish, 
surface  texture,  or  surface  topography. 

♦  First  article  test  requirements.  Preproduction  testing,  inspection,  and  re¬ 
porting  required  to  ensure  a  manufacturer  is  capable  of  producing  an  item 
in  compliance  with  the  contractual  requirements. 

♦  Heat  treatment.  Requirements  that  describe  the  processes  for  the  specific 
purpose  of  altering  material  properties. 

♦  Higher-level  contract  quality  requirements.  Designation  that  Federal 
Acquisition  Regulation  52.246-11,  Higher-Level  Contract  Quality  Re¬ 
quirement,  is  required. 
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♦  Inspection  requirements.  The  inspections  and  tests  necessary  to  substanti¬ 
ate  that  the  supplies  or  services  furnished  under  contract — including  all 
critical,  major,  or  minor  characteristics — conform  to  contract  requirements. 

♦  Legibility.  All  data  prepared  or  submitted  meet  the  legibility  and  reproduc¬ 
ibility  requirements  of  the  specification  or  standard  controlling  the  media 
in  which  the  data  are  to  be  delivered.  As  a  minimum,  all  lines,  symbols, 
letters,  and  numerals  are  readable. 

♦  License  agreement  (mandatory  when  applicable).  An  agreement  between 
the  data  owner  and  the  government  that  defines  the  government’s  rights  to 
use  the  data. 

♦  Materials  (ballistics).  Materials,  processes,  and  protective  treatment  nec¬ 
essary  to  meet  the  design  requirements  of  an  item,  which  are  identified  on 
the  drawing  or  parts  list  by  reference  to  the  item  identification,  identifica¬ 
tion  cross-reference,  or  the  applicable  specifications  or  standards,  includ¬ 
ing  type,  grade,  class,  or  condition  as  applicable.  The  revision  or 
amendment  symbol  of  the  specification  or  standard  is  not  indicated  unless 
it  can  be  established  that  a  particular  revision  level  or  existing  amendment 
has  a  critical  relationship  to  drawing  interpretation  or  item  function.  Addi¬ 
tional  reference  to  other  equivalent  specifications  is  permitted. 

♦  NSN.  A  National  Stock  Number  is  simply  the  official  label  applied  to  an 
item  of  supply  that  is  repeatedly  procured,  stocked,  stored,  issued,  and 
used  throughout  the  federal  supply  system.  It  is  a  unique  item-identifying 
series  of  numbers.  When  an  NSN  is  assigned  to  an  item  of  supply,  data  are 
assembled  to  describe  the  item. 

♦  Nuclear.  Metadata  indication  of  nuclear  technology  requirements  (nuclear 
hardness,  nuclear  propulsion,  etc.). 

♦  Part  number.  The  identifier  assigned  by  the  original  design  activity,  or  by 
the  controlling  nationally  recognized  standard,  that  uniquely  identifies 
(relative  to  that  design  activity)  a  specific  item. 

♦  Restrictions  (mandatory).  Classification,  export  control,  limited  data 
rights,  limited  distribution,  or  any  other  requirement  that  would  restrict 
distribution  of  the  document. 

♦  Revision  and  date  (mandatory).  Changes  made  to  an  original  drawing  or 
associated  document  after  authorized  release  that  require  the  revision  level 
to  be  advanced. 

♦  Revision  type.  Metadata  indication  of  whether  the  revision  level  is  identi¬ 
fied  by  alpha  numeric  or  date  only. 


A-3 


♦  Rights  in  data  (mandatory).  Proprietary  restrictions,  such  as  limited  rights 
and  licensing  rights,  are  marked  on  applicable  drawing  sheets  with  the  ap¬ 
propriate  approved  legend.  Care  is  taken  to  ensure  the  legend  is  delineated 
in  the  field  of  the  drawing,  within  the  margins.  On  drawings  that  are  repro¬ 
duced  in  segments,  the  legend  should  appear  in  each  segment.  Drawings  in 
book-form  need  only  delineate  the  legend  on  the  title  sheet. 

♦  Security  code.  Metadata  field  indication  of  the  security  level  (Confidential, 
Secret,  or  Top  Secret)  of  classified  documents. 

♦  Size  of  drawing,  number  of  sheets,  frames.  Format  size  designation  letter 
according  to  ASME  Y14.1.  Drawing  size  does  not  apply  to  3D  PDF. 

♦  Sources.  The  “approved”  or  “suggested”  sources  are  identified  when  re¬ 
quired  for  the  drawing  type  per  ASME  Y.  14.24. 

♦  Specifications.  A  document  that  describes  essential  technical  requirements 
for  material  and  the  criteria  for  determining  whether  those  requirements 
are  met. 

♦  SUBSAFE.  Metadata  indication  of  Navy  Submarine  SUBSAFE  Program 
requirements. 

♦  Tech  data  availability  code.  Metadata  field  indicating  the  overall  availabil¬ 
ity  or  condition  of  the  data  (legibility,  classification,  limited  rights,  etc.). 

♦  Temper.  Requirements  that  describe  the  degree  of  hardness  and  elasticity 
in  the  material. 

♦  Tolerances  (mandatory).  The  total  amount  by  which  a  specific  dimension 
is  permitted  to  vary.  The  tolerance  is  the  difference  between  the  maximum 
and  minimum  limits. 

♦  Welding  requirements.  Requirements  via  notes,  symbols,  and  annotations, 
or  specifications  that  describe  the  welding  processes. 
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Appendix  B 

Provisioning  and  Cataloging 
Process  Definitions 


Figure  2-1  and  Figure  3-1  contain  a  variety  of  icons  representing  the  various  data 
artifacts  and  procedure  steps  that  occur  during  the  provisioning  and  cataloging 
processes.  This  appendix  details  each  of  the  icons  (listed  in  alphabetical  order): 

♦  3D  Models.  Technical  data — such  as  part/assembly  diagrams  and  illustra¬ 
tions,  including  dimensions,  tolerances,  and  finish — documented  as  a  3D 
model  derived  from  the  OEM  native  CAD  software  package  (CATIA,  for 
example)  used  to  create  the  system  design. 

♦  3D  PDF.  A  document  (ISO  standard  32000)  that  displays  3D  technical 
data  and  PMI  in  a  PRC  format.  A  neutral  file  format,  3D  PDF  can  be  read 
using  Adobe  Acrobat  or  (free)  Adobe  Reader  software,  enabling  the  infor¬ 
mation  to  be  easily  shared  across  many  organizations  without  the  need  to 
purchase  expensive  software  or  training.  The  format  enables  the  user  to 
pan,  tilt,  zoom,  and  rotate  the  geometric  object  depicted  in  the  file.  A  3D 
PDF  document  is  a  validated  derivative  of  the  native  CAD  model  that  de¬ 
fines  the  system/equipment  design  and  includes  geometry,  PMI,  and  other 
relevant  technical  information,  including  procurement  metadata,  to  sup¬ 
port  the  provisioning,  cataloging,  and  sustainment  processes. 

♦  Create  and  Validate  3D  PDF.  Process  of  converting  a  3D  model  from  its 
native  CAD  format  (CATIA,  for  example)  into  a  PDF  neutral  file  format. 
Conversion  includes  using  designated  3D  PDF  conversion  software  to  ap¬ 
ply  a  template  that  defines  the  format  of  the  3D  PDF  output  file.  After  the 
conversion  process,  the  converted  3D  PDF  file  is  validated  against  the  3D 
native  CAD  model  to  ensure  proper  transfer  of  geometry,  PMI,  and  other 
relevant  technical  information,  including  procurement  metadata  to  support 
the  provisioning,  cataloging,  and  sustainment  processes. 

♦  DMS.  The  DMS  is  a  computer  application  that  interacts  with  users,  other 
applications,  and  databases  to  capture,  store,  and  analyze  data.  The  DMS 
stores  drawings/3D  models  and  other  provisioning  technical  documenta¬ 
tion  used  to  convey  design,  development,  production,  manufacture,  assem¬ 
bly,  operation,  repair,  testing,  maintenance,  or  modification  information 
regarding  system/equipment  parts.  The  system  is  used  by  product  data 
specialists  at  DLA  procurement  centers  (such  as  Land  and  Maritime,  Avi¬ 
ation,  and  Troop  Support)  to  identify  and  assemble  a  technical  data  pack¬ 
age  (TDP)  describing  the  technical  characteristics  of  a  specific  part.  The 
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TDP  is  included  in  a  solicitation  requesting  supplier  bids  for  the  manufac¬ 
ture  of  the  specific  part.  Subsequently,  the  TDP  becomes  part  of  a  contract 
and  forms  the  basis  for  determining  whether  the  manufactured  item  meets 
the  required  technical  characteristics. 

♦  FLIS.  The  FLIS  is  the  foundation  for  all  U.S.  government  logistics  infor¬ 
mation  systems.  It  contains  information  for  more  than  16  million  supply 
items  used  by  the  U.S.  government  and  its  North  Atlantic  Treaty  Organi¬ 
zation  (NATO)  partners.  FLIS  provides  a  cross-referenced  list  of  NSNs, 
manufacturer  part  numbers,  and  CAGE  codes  supplemented  with  related 
technical  data,  including  an  alternate  parts  breakdown  list.  It  also  contains 
a  list  of  registered  users,  acquisition  advice  code,  unit  price,  unit  of  issue, 
source  of  supply,  freight  data,  and  hazardous  material  indicators,  inter¬ 
changeable  and  substitutable  information. 

♦  ICAPS.  The  ICAPS  is  a  data  management  system  that  stores,  manages, 
and  distributes  provisioning  data  in  various  formats.  The  provisioning  data 
summaries  contain  information  the  government  needs  to  assess  design  sta¬ 
tus,  conduct  logistics  planning  and  analysis,  influence  program  decisions, 
and  verify  that  contractor  performance  meets  system  supportability  re¬ 
quirements. 

♦  JEDMICS.  The  JEDMICS  is  a  DoD  standard  engineering  data  manage¬ 
ment  and  repository  system.  JEDMICS  provides  the  means  to  efficiently 
convert,  store,  protect,  process,  locate,  receive,  and  output  information 
previously  contained  on  aperture  cards  and  paper.  Large  engineering 
drawings  and  related  text  are  scanned  and  stored  on  network-accessible 
digital  media,  providing  online  access  at  distributed  workstations. 
JEDMICS  is  also  DoD’s  standard  repository  system  for  digitized  engi¬ 
neering  drawings  (3D  models)  and  provides  the  capability  to  accept  data 
directly  from  various  other  digital  media  processes.  It  is  a  joint  service 
program  of  record  with  the  joint  program  office  residing  within  NAVAIR 
(AIR  6.8.4. 1). 

♦  Maintenance  Plan.  The  foundation  document  for  logistics  support  plan¬ 
ning.  It  provides  overall  guidance  on  how  maintenance  will  be  performed, 
the  level  at  which  it  will  be  performed  (organizational,  intermediate,  or  de¬ 
pot),  and  the  support  requirements  at  each  level.  Maintenance  plans  typi¬ 
cally  are  distributed  to  the  cognizant  program  support  inventory  control 
point,  cognizant  field  activities,  logistics  managers,  logistic  element  man¬ 
agers,  operational  commanders  (who  will  use  the  fielded  the  equipment), 
and  other  logistics  support  activities  for  implementation. 

♦  NSN/Part  Characteristics.  The  NSN  is  a  unique  13-digit  numeric  code, 
used  to  identify  standard  material  items  of  supply  for  NATO  and  DoD. 

Part  characteristics  of  an  item  provide  detailed  item  descriptions,  including 
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information  such  as  materials,  dimensions,  colors,  conditions,  and  perfor¬ 
mance  characteristics  of  supply  parts.  Also  included  are  several  data  ele¬ 
ments  that  identify  usage,  who  manages  the  item,  and  how  to  dispose  of 
the  item  at  the  end  of  its  life  cycle. 

♦  Perform  Provisioning.  Provisioning  is  the  process  of  determining  and  ac¬ 
quiring  the  range  and  quantity  (depth)  of  repair  parts  and  support  and  test 
equipment  required  to  operate  and  maintain  an  end  item  of  material  for  an 
initial  period  of  service.  The  provisioning  process  makes  technical  deci¬ 
sions  on  each  part  by  addressing  a  series  of  maintenance  questions.  An¬ 
swers  to  these  technical  maintenance  questions  translate  into  language 
used  in  the  supply  system.  Typical  maintenance  questions  include  “Should 
the  part  be  stocked?”  “Who  can  replace  the  part?,”  “Who  can  repair  the 
part?,”  “Who  is  the  disposal  authority?,”  “What  is  the  expected  replace¬ 
ment  frequency?,”  “What  is  the  expected  replacement  quantity?,”  and 
“What  preventive  maintenance  is  required?”  Once  made,  the  technical  de¬ 
cisions  are  recorded  by  the  assignment  of  codes  associated  with  each  part. 

♦  Perform  Screening.  A  comprehensive  review  of  available  technical  data  to 
identify  incomplete,  incorrect,  or  duplicate  information  that  might  hamper 
the  cataloging  process.  Screening  is  an  optional  service  available  through 
DLA  LIS  that  must  be  specifically  requested  by  the  provisioning  activity 
(such  as  NAVSUP);  it  is  normally  conducted  early  in  the  provisioning 
process. 

♦  PLM.  A  PLM  system  is  a  data  management  system  that  stores,  manages, 
and  distributes  data  and  design  information  (such  as  3D  models,  mainte¬ 
nance  plans,  or  PPLs)  associated  with  the  life  of  a  product  from  concept 
development,  to  system  design,  to  manufacture/production,  and  through 
system  sustainment  to  its  retirement  and  disposal. 

♦  PPL.  Portrays  the  physical  composition  of  the  system  or  equipment.  It  is  a 
list  of  parts  that  make  up  the  complete  assembly  of  the  finished  product.  It 
includes  all  items  subject  to  wear  or  failure  and  other  items  required  for 
maintenance  throughout  the  expected  life  cycle  of  the  end  item.  Parts  are 
listed  in  a  logical  order,  such  as  a  top-down-breakdown  or  circuit  symbol 
sequence.  For  each  part,  the  PPL  shows  information  such  as  the  part  num¬ 
ber,  part  name,  and  quantity  of  the  part  in  the  equipment,  unit  price  of  the 
item,  etc.  The  PPL  is  the  basic  document  used  in  the  provisioning  process 
for  recording  various  technical  decisions  regarding  the  maintenance  signif¬ 
icance  of  an  item,  how  it  will  be  used,  and  where  it  will  be  used. 

♦  Share  Drive.  Access-controlled  digital  storage  repository  located  and 
available  via  a  local  area  network.  The  share  drive  is  accessible  only  by 
personnel  associated  with  the  activity  that  owns  it.  It  is  used  to  store  vari¬ 
ous  forms  of  technical  data. 
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♦  Technical  Library.  NAVSUP-controlled  digital  storage  repository  availa¬ 
ble  via  a  local  area  network.  It  is  used  to  store  drawings  and  3D  models  for 
weapon  systems  and  equipment  for  which  NAVSUP  is  the  cognizant  pro¬ 
visioning  activity. 

♦  SSR.  The  SSR  is  a  formal  document  sent  by  a  provisioning  activity  (such 
as  NAVSUP)  to  LIS,  requesting  issuance  of  new  NSNs  for  appropriate 
items  and  informing  DLA  of  added  supply  requirements  for  existing 
NSNs.  The  SSR  initiates  the  cataloging  process. 

♦  Perform  Cataloging.  The  process  of  creating  an  NSN  for  each  part  used  to 
maintain  a  weapon  system/equipment.  Cataloging  serves  as  the  foundation 
of  the  DoD  supply  chain,  ensuring  information  on  each  part  is  provided  in 
a  way  that  enables  supported  activities  to  easily  understand  and  use  it.  Cat¬ 
aloging  includes  naming,  describing,  and  numbering  each  item  recurrently 
used,  bought,  stocked,  or  distributed  by  the  DoD,  other  federal  agencies, 
and  international  allies. 

♦  SCAN  DATA.  LIS-controlled  digital  storage  repository  used  to  store 
NATO,  U.S.  military  service,  and  manufacturer  systems/equipment  draw¬ 
ings  and  models  to  support  cataloging  activities. 

♦  Tech  Data.  Information  used  to  catalog  and  assign  an  NSN.  It  includes 
drawings/3D  models  and  other  provisioning  technical  documentation  used 
to  convey  design,  development,  production,  manufacture,  assembly,  oper¬ 
ation,  repair,  testing,  maintenance,  or  modification  information  regarding 
system/equipment  parts. 


B-4 


Appendix  C 

Abbreviations 


2D 

two-dimensional 

3D 

three-dimensional 

ASME 

American  Society  of  Mechanical  Engineers 

BCA 

business  case  analysis 

CAD 

computer-aided  design 

CAGE 

Commercial  and  Government  Entity 

DLA 

Defense  Logistics  Agency 

DoD 

Department  of  Defense 

DMS 

Data  Management  System 

EDFP 

engineering  data  for  provisioning 

ESA 

engineering  support  activity 

FCS 

Federal  Catalog  System 

FLIS 

Federal  Logistics  Information  System 

ICAPS 

Interactive  Computer  Aided  Provisioning  System 

ITI 

International  TechneGroup  Incorporated 

JEDMICS 

Joint  Engineering  Data  Management  Information  and 
Control  System 

LIS 

Logistics  Information  Services 

MANTECH 

DoD  Manufacturing  Technology  Program 

NATO 

North  Atlantic  Treaty  Organization 

NAVAIR 

Naval  Air  Systems  Command 

NAVSUP 

Naval  Supply  Systems  Command 

NA 

not  applicable 

NC 

numerical  control 

NSN 

National  Stock  Number 

OEM 

original  equipment  manufacturer 

PLM 

product  life  cycle  management 

PMI 

product  and  manufacturing  information 

C-l 


PRC 

product  representation  compact 

PPL 

provisioning  parts  list 

R&D 

research  and  development 

SME 

subject  matter  expert 

SSR 

supply  support  request 

STEP 

Standard  for  the  Exchange  of  Product  model  data 

TDP 

technical  data  package 

USMC 

United  States  Marine  Corps 

WSS 

Weapon  Systems  Support 
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